Manage Yourself. Rapport de modélisation. Projet de 4ème année informatique. Equipe :

Transcription

1 Manage Yourself Rapport de modélisation Projet de 4ème année informatique Equipe : Etienne Alibert, Florian Barbedette, Pierre Chesneau, Mathias Deshayes, Sevan Hartunians, Mathieu Poignet. Encadrant : Laurence Rozé 1 Le 19/02/2010

2 Sommaire Introduction... 4 I. Conception générale du logiciel... 5 II. Génération de rapports... 6 A. Rappel des spécifications... 6 B. Données présentes dans les rapports... 6 C. Diagramme de classes... 7 D. Diagramme de séquence... 8 III. Communication... 9 A. Conception... 9 B. Tests de communications MediaContact Tests entre deux postes fixes Tests avec un client sur appareil mobile IV. Système expert A. Conception Statique Les faits Les règles et les actions La base de connaissances Le moteur d inférence B. Conceptions dynamiques Diagramme de séquence global Diagramme de séquence d ExecuteunPas V. Apprentissage A. Conception du simulateur Les attributs Les règles Les exemples Algorithme d apprentissage Diagramme de classes B. Conception du lecteur de système expert Les attributs Les règles Diagramme de classes

3 4. Javacc C. Conception de l interface administrateur Conclusion

4 Introduction Ce projet intitulé «Manage Yourself» consiste à développer un logiciel de diagnostic pour Smartphone et Pocket PC. Comme nous l avons décrit dans le rapport de spécification, ce programme est découpé en deux parties, une application sur le mobile qui doit être invisible à l utilisateur et une partie sur le serveur. Nous avons divisé chacune de ces parties en deux sous-parties. Sur le serveur nous avons une partie communication qui permettra d envoyer le système expert au mobile, et une autre partie qui consistera à apprendre des exemples de plantage. Sur le mobile, une partie servira à la génération de rapport pour le système expert et pour l apprentissage. L autre partie sera le système expert qui, grâce aux rapports, surveillera en temps réel le système mobile. Ce document a pour objectif de décrire l architecture logicielle de notre projet. Nous y décrivons l ensemble des interactions entre nos différents modules ainsi que la modélisation de chacun d eux. Pour ce faire, nous expliciterons la modélisation statique à l aide de diagramme de classes, et la modélisation dynamique à l aide de diagramme de séquence. 4

5 I. Conception générale du logiciel Le projet Manage Yourself peut se modéliser de manière simplifiée selon le diagramme suivant. Figure 1 - Conception générale de l'application 5

6 II. Génération de rapports A. Rappel des spécifications L application de génération de rapports est l application présente sur le mobile et qui sert d une part à fournir les faits au système d experts et d autre part à alimenter en exemple la partie apprentissage du projet qui, elle, est située sur le serveur. Les rapports posséderont tous une étiquette : Plantage de Windows mobile (si le mobile s éteint de façon non volontaire) Plantage de l application X Aucun plantage (servant d exemple négatif pour l apprentissage) Cette application doit être complètement invisible à l utilisateur, et ne doit pas occuper trop de mémoire vive. B. Données présentes dans les rapports Les rapports contiendront les données qui nous semblent pertinentes à observer dans le but de prévenir d un plantage. Nous pouvons regrouper ces données dans les catégories suivantes : Bluetooth Mémoire Périphériques Carte SIM Appels Réseaux WIFI Batterie Ces informations seront collectées grâce aux méthodes de la DLL coredll, ainsi que de la classe SystemState. 6

7 C. Diagramme de classes Figure 2 - Diagramme de classes de génération de rapports Le programme possède trois classes. La classe Application est le point d entrée du programme, comme nous le verrons dans le diagramme de séquence, c est cette classe qui va gérer la génération de rapports. Cette classe possède un attribut rapport_courant, qui lui permet à tout moment de déclencher la conversion de l objet rapport en fichier binaire. La classe application possède également un timer, qui permettra de générer les rapports de façon régulière. A chaque top du timer, l application transforme son rapport_courant en fichier binaire. La classe abstraite rapport permet de changer facilement le type de rapport que l on veut obtenir. Il suffit pour cela de créer une classe qui hérite de rapport (ici cette classe sera rapport_concret) qui contient en attribut les informations que l on désire observer et de surcharger la méthode generationrapport. 7

8 D. Diagramme de séquence Figure 3 - Diagramme de séquence de génération de rapports 8

9 Au démarrage de l application la méthode aplante() est appelée, cette méthode indique si le dernier arrêt s est fait sur un plantage ou non. Si c est le cas alors on étiquette le dernier rapport (en le renommant) comme un plantage du système. Ensuite le système se place en attente du timer. Une fois que celui-ci envoie un top, alors le programme vérifie qu il existe bien deux fichiers (un fichier destiné à l apprentissage et l autre au système expert). Si ce n est pas le cas, il crée ces fichiers. En revanche s ils existent tous les deux, on écrase seulement le fichier servant au système expert car cela signifie que le serveur n a pas encore récupérer le rapport servant à l apprentissage. La méthode tobinaryfile(string) permet de créer les fichiers binaires de rapport, le paramètre indique si ce fichier est destiné à l apprentissage ou au système expert. III. Communication A. Conception La partie communication client/serveur de notre application est gérée via le logiciel MediaContact de TELELOGOS. Ce logiciel permet d'exécuter des processus à distance sur le client, mais aussi des processus sur le serveur. Nous avons donc défini 2 processus utiles: Le premier processus Abonnement est lancé à l'abonnement du téléphone à notre application. Il permet de transférer l'exécutable de notre application sur la station cliente via une première tâche fille du processus Abonnement. En effet MediaContact permet de copier des fichiers d'un répertoire source vers un répertoire destination. La seconde tâche de ce processus permet d'exécuter à distance le fichier MY.exe que nous venons de transférer. La Figure suivante présente le diagramme de séquence expliquant le fonctionnement du processus «Abonnement». Figure 4 - Diagramme de séquence du processus Abonnement 9

10 On voit ainsi que l'on se sert des méthodes «copier et exécuter» de MediaContact. Les paramètres «serverout» et «stationin» représentent respectivement les dossiers Out et In du serveur et de la station. Ces 2 paramètres sont accessibles via des primitives MediaContact. Le deuxième processus «RecupRapport» permet de récupérer le rapport sur les clients et de le concaténer avec les rapports déjà existants, et ce afin de générer un fichier qui sera pris en entrée de l'apprentissage. Ce processus est composé de trois tâches filles: La tâche déplacée (StationOut, ServerIn, Rapport.bin): Elle permet de déplacer du dossier StationOut vers le dossier ServerIn le fichier binaire contenant le rapport généré par l'application Manage Yourself. La tâche déplacée est une tâche prédéfinie de MediaContact. La tâche exécuter(compilateur(rapport.bin)): Elle permet d'exécuter un compilateur écrit en prolog qui permettra de prendre en entrée un fichier binaire, et de générer du code arff, format qui est pris en entrée de l'apprentissage. Ce compilateur étant exécuté sur le serveur, nous avons le choix du langage dans lequel ce compilateur est écrit. Nous avons choisi le langage Prolog car il est très facile d'implémenter un compilateur simple comme celui dont nous avons besoin. La tâche concaténée: La dernière tâche permet de concaténer le nouveau rapport qui est maintenant au format arff avec les anciens rapports. Cette tâche se fait via l'appel d'une commande système Windows, méthode présente dans MediaContact. La commande système utilisée est: type %serverin%/rapport.arff >> %ServerIn%/apprentissage.arff. La figure ci-après présente le diagramme de séquence du processus «RecuRapport». Figure 5 - Diagramme de séquence du processus RecuRapport 10

11 B. Tests de communications 1. MediaContact Afin d'établir une communication entre le serveur et le client, nous utilisons le logiciel Mediacontact de notre entreprise partenaire : Telelogos. Il existe un logiciel Mediacontact serveur, accompagné d'une console d'administration, permettant de gérer l'ensemble des communications. Il faut déployer un logiciel client sur chaque station cherchant à communiquer avec le serveur, il existe plusieurs types de clients en fonction du type de la station : poste fixe, appareil mobile... Figure 6 - Fonctionnement de Mediacontact 2. Tests entre deux postes fixes Pour commencer, nous avons tout d'abord essayé d'établir une communication entre un serveur et un client, chacun situé sur un poste fixe. Afin d'avoir toujours accès au serveur, nous avons installé le serveur et sa console d'administration sur le poste pc1-info10 du département informatique. Ce poste a la particularité de ne jamais être éteint car il sert de serveur de licences. Ce poste est situé dans le réseau educ. Nous avons installé le client sur le poste pc1-info1, ce poste faisant également partie du réseau educ. Nous avons réalisé nos tests de transferts entre ces deux postes : des transferts de fichier depuis le serveur vers le client, ainsi que depuis le client vers le serveur, l'appel de commandes tel que la concaténation de deux fichiers. Nous avons ainsi pu tester tous les éléments nécessaires à la partie communication du projet tels qu ils ont été décrits dans la partie «Modélisation des communications». 11

12 3. Tests avec un client sur appareil mobile Nous avons ensuite décidé de réitérer ces tests mais cette fois avec le client spécifique pour appareil mobile. Pour cela nous avons utilisé le PDA que nous a fourni l'entreprise Telelogos pour effectuer nos tests. Ce PDA est un HP ipaq rx1950 avec Windows mobile 5.0 d'installé, et possède une carte wifi. Nous avons donc installé le client Mediacontact pour Windows mobile sur ce PDA. L'INSA possède un réseau wifi Insawifi qui permet aux étudiants et professeurs de se connecter au réseau educ, mais les paramètres de sécurité de ce réseau ne permettent pas à un appareil sur Windows mobile de s'y connecter. Le CRI nous a donc créé un réseau particulier afin de réaliser nos tests. Nous n'avons par contre toujours pas pu établir une communication entre le serveur et le client mobile. IV. Système expert A. Conception Statique Le système expert est la partie du logiciel gérant l aspect décisionnel. À partir d une base de connaissances, il doit être capable suivant les faits existants de déduire des informations et d exécuter des actions suivant des règles. 1. Les faits Les faits sont une entité à part entière du système. Ils peuvent êtres classés en deux groupes : les faits instanciés et les faits non instanciés. Un fait instancié est l association d un fait non instancié et de sa valeur. Par exemple : la couleur du ciel est un fait (le ciel à une couleur, mais on ne sait pas laquelle) et un fait instancié associé pourrait être «la couleur du ciel est : bleu» Dans le système expert, un fait non instancié à l instant T peut devenir instancié à l instant T+1, du fait des déductions faites par le moteur d inférence. Il faut donc que ces 2 entités soient interchangeables. Pour plus de facilité nous avons choisi de fusionner ces 2 classes : Il n existe donc qu une seule classe fait pouvant contenir de 0 à 1 valeur (0: le fait n est pas instancié ; 1 le fait est instancié). 2. Les règles et les actions Les règles sont les liens entre des conditions et des actions. Lorsque les conditions d une règle sont validées : les actions associées (ajouter de nouveaux faits instanciés et/ou exécuter une action) sont effectuées. Nous pouvons donc ici extraire plusieurs entités : les actions, les faits, les règles et les conditions. 12

13 Les actions peuvent être de 2 types : les actions «ajout de fait» qui permettent de faire grossir la base de connaissances et les actions «correctives» qui dans notre système permettrons d exécuter un point d entrée d une DLL. Une condition (sachant qu une règle peut contenir de 1 à n conditions) est constituée de 2 parties : un opérande droit, un opérateur et un opérande gauche. Pour simplifier la mise en œuvre, nous avons fait l hypothèse que seule la partie droite de la condition pouvait comporter une valeur (c.à.d. que l on ne prend en compte que les conditions de la forme Fait operateur valeur et non Valeur operateur Fait. Ceci est possible dans notre contexte puisque les différents opérateurs proposés ne sont que des opérateurs logiques ayant chacun leur contraire). Nous avons également choisi, pour simplifier là mise en œuvre, de ne pas créer de classe opérateur. Les opérateurs seront stockés sous forme de chaines de caractères, et seront traités par les fonctions operator de la classe valeur. 3. La base de connaissances La base de connaissances est la «mémoire» du système expert. Elle contient toutes les règles d inférences, les faits (instanciés ou non) existant dans les règles, et des méthodes d accès et de modification des données. Nous voulions que cette classe soit la moins dépendante du format des données qu elle traitera. C est pour cette raison qu existe la classe import, elle permettra d ajouter à la base de connaissances de nombreux faits et /ou règles en une fois (dans notre cas à partir des fichiers de rapport). 4. Le moteur d inférence Le moteur d inférence est une stratégie de la base de connaissances. On pourra remarquer sur le diagramme de classe qu il s agit d une interface et que nous avons choisi de n implémenter que le chainage avant. L implémentation d un système d inférence plus rapide, plus efficace ou utilisant un autre algorithme étant toujours possible ultérieurement. 13

14 Figure 7 - Diagramme de classes du système expert 14

15 B. Conceptions dynamiques Plutôt que de passer en revue toute les étapes du fonctionnement de notre système, nous avons choisi de ne détailler que les aspects plus délicats de notre diagramme. 1. Diagramme de séquence global La fonction execute, chargée de faire grossir la base de connaissances se base sur la fonction executeunpas qui elle, fait une itération pour augmenter les données de la base de connaissances. Elle passe en revue toutes les règles une fois et s assure qu elles sont applicables (tous les faits des conditions de la règle sont instanciés) et valides (la condition est vérifiée). Pour fonctionner correctement la fonction execute à besoin de savoir si la base de connaissance a été augmentée depuis le dernier pas. Ceci explique la présence des deux fonctions estmodifiee() et razmodifiee() qui permettent de connaitre si depuis le dernier appel à razmodifiee() la base de connaissances a été modifiée. Figure 8 - Diagramme de séquence global du système expert 2. Diagramme de séquence d ExecuteunPas Ce diagramme ne présente que le cas où la règle choisie est exécutable et validée. Dans le cas contraire, les fonctions isapplicable ou isvalid retourneraient faux, cette valeur se propageant dans l arbre d appel jusqu'à revenir au niveau de executeunpas qui passerait alors à l évaluation /test de la règle suivante. ExecuteUnPas procède de cette manière jusqu'à avoir passé en revue une fois exactement chaque règle d inférence (que ces règles aient été applicable et/ou valide n a pas d importance). 15

16 Figure 9 - Diagramme de séquence de executeunpas 16

17 V. Apprentissage Dans la partie apprentissage nous avons dégagé deux grandes parties à implémenter : le simulateur et l interface administrateur. Pour l apprentissage en lui même nous n avons rien à concevoir puisque nous allons utiliser la bibliothèque Weka. Le simulateur prend en entrée des règles et un entier correspondant au nombre d exemples à générer et retourne un fichier contenant les exemples générés. L interface administrateur prend en entrée deux fichiers l un correspondant aux règles du système expert déjà utilisées et l autre correspondant aux règles apprises. Elle permet alors d ajouter ou de modifier les règles du système expert et de les sauvegarder dans un nouveau fichier. Lors de la conception de ces deux entités nous nous sommes aperçus qu il fallait modéliser un pseudo système expert pour pouvoir stocker ses attributs et ses règles sans aller jusqu au moteur d inférence. Or ce système expert est très proche du simulateur dans le sens où il possède des attributs et des règles comme le simulateur. Nous avons donc introduit une classe MachineARegle pour stoker tous les éléments communs au simulateur et aux systèmes experts. La suite du chapitre va comporter trois parties : la conception du simulateur, la conception du système expert pour une simple mémorisation des règles et des attributs, la conception de l interface administrateur. A. Conception du simulateur Dans notre logiciel final, les Smartphones enverront à un serveur des rapports. Ces rapports contenant des exemples sous la forme : memoire=256 applicationa=lancee applicationb=lancee applicationc=lancee dernière- VersionA=oui derniereversionb=oui dernièreversionc=oui batterie=normale plantage=oui Ces exemples instancient des variables (mémoire, applicationa, applicationb,applicationc, derniereversiona, derniereversionb, derniereversionc, batterie) et sont étiquetés par un attribut cible appelé ici plantage. Pour pouvoir commencer l étude de l apprentissage sans attendre la mise en œuvre de la gestion des rapports nous avons décidé de développer un petit simulateur dont le rôle est de créer les rapports que pourraient générer des Smartphones régis par des règles assez simples (règles portant sur la valeur des attributs). Dans la suite, nous allons présenter plus en détail les attributs que nous allons utiliser. Puis nous détaillerons les formes de règles acceptées par le simulateur, ainsi que l algorithme d apprentissage utilisé. Enfin, nous présenterons notre diagramme de classes. 1. Les attributs Les attributs sont définis par un nom et un domaine. Le domaine peut être de deux types : discret ou numeric. Ce choix vient de l utilisation de la bibliothèque Weka pour l apprentissage qui ne traite que ces deux types d memoire applicationa applicationb applicationc derniereversiona derniereversionb derniereversionc {oui,non} 17

18 @attribute batterie plantage {oui,non} 2. Les règles Les conditions d une règle peuvent être : des tests d égalité ou d inégalité à une valeur ou à un autre attribut, des tests de comparaison et des tests d appartenance à un domaine, que ce soit discret ou continu. La grammaire définissant l ensemble des règles possibles est la suivante : Regle SI (nomattribut test) suiteregle FSI suiteregle (ET nomattribut test)* test testegalite testcomparaison testappartenace testegalite (=!=) valeur testcomparaison comparaison valeur comparaison > < _ _ valeur nomattribut valeurattribut testappartenance appartient domaine domaine domaineentier domainediscret domainediscret { valeurattribut (, valeurattribut)* } domaineentier [ entier, entier] On peut remarquer que l on a limité le pouvoir d expression des règles de deux façons : l opérande gauche des conditions est nécessairement un attribut et la partie droite de la règle est nécessairement «plantage = oui». Le premier simulateur que l on développera implémentera les 3 règles suivantes : memoire є presquesaturee,saturee ^ applicationc=lancee ) plantage=oui memoire = saturee ^ applicationa=lancee ) plantage=oui applicationa = lancee ^ applicationb=lancee ) plantage=oui 3. Les exemples Les exemples générés vont directement être stockés dans un fichier au format.arff (format d entrée pour les algorithmes d apprentissage de la bibliothèque Weka). Ils pourront être ainsi directement chargés dans Weka et on pourra lancer l apprentissage dessus sans aucune adaptation à faire. Voici un exemple de fichier pouvant être généré par le premier simulateur que l on memoire {normale, saturee, applicationa {lancee, applicationb {lancee, applicationc {lancee, derniereversiona {oui, derniereversionb {oui, derniereversionc {oui, batterie {normale,faible, plantage {oui, normale, lancee, lancee, nonlancee, oui, oui, non, faible, oui presquesaturee, lancee, lancee, nonlancee, oui, non, non, normale, oui 18

19 presquesaturee, nonlancee, lancee, lancee, oui, non, oui, normale, oui presquesaturee, lancee, lancee,lancee,non,oui, oui, vide, oui presquesaturee, lancee, lancee, lancee, oui, oui, non, vide, oui normale, lancee, lancee, lancee, oui, oui, non, vide, oui presquesaturee, lancee, nonlancee, nonlancee, oui, non, oui, normale, non On y trouve dans un premier temps le nom du concept à apprendre : Smartphone1, puis la description de chacun des attributs, sous la forme nom, domaine, puis les exemples en eux même avec la valeur des attributs dans l ordre de leur déclaration. 4. Algorithme d apprentissage Dans un premier temps l algorithme J48 sera utilisé pour apprendre des arbres de décision. J48 est une mise en œuvre de l algorithme C4.5 de Quinlan. Les paramètres seront fixés à 2 exemples au minimum par feuille, et à un facteur de confiance de 0,25 pour l élagage. L apprentissage des arbres sera effectué avec une validation croisée à 10 tours. 5. Diagramme de classes Le diagramme de classes suivant (Figure 10) montre la structure d un simulateur : il est composé d un ensemble d attributs et d un ensemble de règles. Un attribut est constitué d un nom, d un domaine et d une valeur. Figure 10 - Diagramme de classes du simulateur 19

20 Le diagramme de classes de la figure 11 montre la structure d une règle. Une règle est constituée d un ensemble de conditions. Une condition est constituée d un opérande gauche qui est nécessairement un attribut, d un opérateur et d un opérande droit qui peut être un attribut, une valeur ou un domaine (que soit discret ou entier). Figure 11 - Diagramme de classes d une règle B. Conception du lecteur de système expert 1. Les attributs Les attributs sont définis comme pour le simulateur : par un nom et un domaine. Le domaine peut être de deux types : discret ou numeric (seuls types utilisés par memoire applicationa {lancee, applicationb {lancee, applicationc derniereversiona {oui, derniereversionb {oui, derniereversionc {oui, batterie {normale, faible, plantage {oui, non} 20

21 2. Les règles Les conditions d une règle peuvent être : des tests d égalité ou d inégalité à une valeur ou à un autre attribut. Nous n avons plus ici la notion d appartenance à un domaine. En effet les algorithmes implémentés dans la bibliothèque Weka ne permettent pas d apprendre des règles avec des appartenances. Ceci ne limite pas le pouvoir d expression des règles apprises car une appartenance à un domaine discret est équivalente à un nombre fini de règles d égalité et l appartenance à un domaine numérique est équivalente à deux règles d inégalité. La grammaire définissant l ensemble des règles possibles est la suivante : regle SI (nomattribut test) suiteregle ALORS partiedroite FSI suiteregle (ET nomattribut test)* test testegalite testcomparaison testegalite (=!=) valeur testcomparaison comparaison valeur comparaison > < _ _ valeur nomattribut valeurattribut partiedroite (action)+ action affectation appel affectation nomattribut = valeur appel APPEL nomattribut Des exemples de règles du système expert sont les suivantes : SI memoire >= 240 SI memoiredist=saturee SI derniereversiona=non ALORS memoiredist=saturee FSI ALORS APPEL libererespacememoire FSI ALORS APPEL chargerderniereversiona FSI Figure 12 - Diagramme de classes du système expert 21

22 3. Diagramme de classes Le diagramme de classes de la figure 12 montre la structure d un système expert. C est une machine à règles : il est composé d un ensemble d attributs et d un ensemble de règles. Mais les règles d un système expert sont des règlesse. Une règlese est une règle à laquelle une partie action a été ajoutée. Une action est soit une affectation, soit un appel de fonctions. 4. Javacc Une fois les classes du diagramme de la figure 12 implémentées, on utilisera un générateur d analyseur syntaxique et lexical pour lire le fichier de règles du système expert. Au fur et à mesure du parcours de la grammaire donnée ci-dessus, on construira le système expert. De la même façon on utilisera javacc pour lire les règles apprises en utilisant Weka. L objet alors construit sera une machine à règle. C. Conception de l interface administrateur L interface administrateur prend en entrée deux fichiers : reglese.mrf et regleapp.mrf et génère un nouveau fichier de règles système expert reglese.mrf. La figure 13 donne un aperçu de l interface. Comme le montre la figure 13, l interface administrateur est constituée de quatre sous fenêtres : Figure 13 - Interface administrateur la fenêtre RegleSE (en haut à gauche) qui contient au lancement les règles du système expert utilisés jusqu à présent et à la fin les nouvelles règles qui seront utilisées par le système expert la fenêtre RegleApp (en haut à droite) qui contient les règles apprises la fenêtre conditions (en bas à gauche) qui permet de saisir ou de modifier un ensemble de conditions la fenêtre actions (en bas à droite) qui permet de saisir les actions associées à une règle. 22

23 Figure 14 - Diagramme de séquence de l ajout d une nouvelle règle Au lancement de l interface seules les fenêtres RegleSE et RegleApp sont activées. Pour pouvoir saisir une règle (et donc activer les fenêtres conditions et actions) il faut soit décider d ajouter une nouvelle règle (en cliquant sur le bouton nouveau) soit décider d étiqueter une règle apprise (en cliquant sur le bouton Etiqueter après avoir sélectionné une règle). A tout moment il est possible de supprimer une règle (en cliquant sur le bouton Supprimer après avoir sélectionné la règle). Ceci peut être utile soit pour supprimer une ancienne règle du système expert soit pour éliminer des règles apprises les règles déjà couvertes par une règle du système expert. Les diagrammes de séquence figure 14 et 15 résume ce fonctionnement. Figure 15 - Diagramme de séquence pour étiqueter une règle apprise 23

24 Les fenêtres conditions et actions fonctionnent exactement sous le même principe : le bouton ajouter permet d ajouter une condition ou une action ; le bouton supprimer permet de supprimer l action ou la condition sélectionnée ; le bouton valider permet de valider la liste de conditions ou d actions saisie. Il n est plus possible alors de modifier cette liste. Le diagramme d état de la figure 16 résume ce fonctionnement. Figure 16 Diagramme d état de la fenêtre condition 24

25 Conclusion Nous venons d'établir la modélisation de notre application. Ainsi nous avons pu découper l'application en 4 parties: la génération de rapports, la communication client/serveur, le système expert et l'apprentissage. La génération de rapports présente une modélisation assez simple, mais son implémentation sera plus difficile car elle ne se prête pas bien à une conception de type objet. La communication client/serveur étant entièrement géré via MediaContact, la modélisation de cette partie fut assez rapide. Cependant, les tests à réaliser furent assez chronophages. Le système expert est une partie qui a nécessité beaucoup de temps au niveau de la modélisation de par sa complexité, cependant l'implémentation s'en trouve grandement facilitée. L'apprentissage s'est décomposé en 2 parties: le simulateur et l'interface administrateur. Le simulateur ne nécessitait pas de conception, car elle se sert de la bibliothèque Weka, et la modélisation de l'interface administrateur permettra une implémentation plus aisée. Chaque module pourra être développé indépendamment, ce qui facilite le fonctionnement en sous-équipes du projet. De plus, la planification préalablement établie étant respectée, il ne nous reste plus qu'à développer ces différentes parties en suivant cette planification. 25