Manage Yourself

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
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 .......................................................................................................... 11
1.
MediaContact ........................................................................................................................ 11
2.
Tests entre deux postes fixes ................................................................................................ 11
3.
Tests avec un client sur appareil mobile ............................................................................... 12
IV.
Système expert .......................................................................................................................... 12
A.
Conception Statique .................................................................................................................. 12
1.
Les faits .................................................................................................................................. 12
2.
Les règles et les actions ......................................................................................................... 12
3.
La base de connaissances ...................................................................................................... 13
4.
Le moteur d’inférence ........................................................................................................... 13
B.
V.
Conceptions dynamiques .......................................................................................................... 15
1.
Diagramme de séquence global ........................................................................................... 15
2.
Diagramme de séquence d’ExecuteunPas ............................................................................ 15
Apprentissage ................................................................................................................................ 17
A.
Conception du simulateur ......................................................................................................... 17
1.
Les attributs ........................................................................................................................... 17
2.
Les règles ............................................................................................................................... 18
3.
Les exemples ......................................................................................................................... 18
4.
Algorithme d’apprentissage .................................................................................................. 19
5.
Diagramme de classes ........................................................................................................... 19
B.
Conception du lecteur de système expert ................................................................................ 20
1.
Les attributs ........................................................................................................................... 20
2.
Les règles ............................................................................................................................... 21
3.
Diagramme de classes ........................................................................................................... 22
2
4.
C.
Javacc..................................................................................................................................... 22
Conception de l’interface administrateur ................................................................................. 22
Conclusion ............................................................................................................................................. 25
3
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
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
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
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
D. Diagramme de séquence
Figure 3 - Diagramme de séquence de génération de rapports
8
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
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
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
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
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
Figure 7 - Diagramme de classes du système expert
14
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
Figure 9 - Diagramme de séquence de executeunpas
16
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
VersionA=oui derniereVersionB=oui dernièreVersionC=oui batterie=normale
dernièreplantage=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’attributs.
@attribute memoire {normale,saturee,presqueSaturee}
@attribute applicationA {lancee,nonLancee}
@attribute applicationB {lancee,nonLancee}
@attribute applicationC {lancee,nonLancee}
@attribute derniereVersionA {oui,non}
@attribute derniereVersionB {oui,non}
@attribute derniereVersionC {oui,non}
17
@attribute batterie {normale,faible,vide}
@attribute 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
suiteRegle
test
testEgalite
testComparaison
comparaison
valeur
testAppartenance
domaine
domaineDiscret
domaineEntier
SI (nomAttribut test) suiteRegle FSI
(ET nomAttribut test)*
testEgalite | testComparaison | testAppartenace
(= | !=) valeur
comparaison valeur
>|<|_—_
nomAttribut | valeurAttribut
appartient domaine
domaineEntier | domaineDiscret
{ valeurAttribut (, valeurAttribut)* }
[ 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 )
memoire = saturee ^ applicationA=lancee )
applicationA = lancee ^ applicationB=lancee )
plantage=oui
plantage=oui
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
implémentera.
@relation smartphone1
@attribute memoire {normale, saturee, presqueSaturee}
@attribute applicationA {lancee, nonLancee}
@attribute applicationB {lancee, nonLancee}
@attribute applicationC {lancee, nonLancee}
@attribute derniereVersionA {oui, non}
@attribute derniereVersionB {oui, non}
@attribute derniereVersionC {oui, non}
@attribute batterie {normale,faible, vide}
@attribute plantage {oui, non}
@data
normale, lancee, lancee, nonLancee, oui, oui, non, faible, oui
presqueSaturee, lancee, lancee, nonLancee, oui, non, non, normale, oui
18
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
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 Weka).
@attribute memoire NUMERIC
@attribute applicationA {lancee, nonLancee}
@attribute applicationB {lancee, nonLancee}
@attribute applicationC {lancee ,nonLancee}
@attribute derniereVersionA {oui, non}
@attribute derniereVersionB {oui, non}
@attribute derniereVersionC {oui, non}
@attribute batterie {normale, faible, vide}
@attribute plantage {oui, non}
20
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
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
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
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
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