Les systèmes d’alerte ou de rappels automatiques

Les systèmes d’alerte ou de rappels automatiques

CONCEPTION D’APPLICATION

Introduction

L’algorithmique qui était utilisé dans la programmation fonctionnelle ne pourrait pas suffire à lui seul. Le besoin d’avoir des méthodes ou langages pour la modélisation des langages orientés objet se faisait sentir. Ainsi plusieurs méthodes ou langages on vu le jour. En occurrence UML qui nous a permis de faire la conception de notre application.

La modélisation du point de vue logique

UML (Unified Modelling language)

Definition

UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.
UML unifie est à la fois les notations et les concepts orientes objet. Il ne s’agit pas d’une simple notation, mais les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au même titre que les mots d’un langage. UML a une dimension symbolique et ouvre une nouvelle voie d’échange de visions systémiques précises, Ce langage est certes issu du développement logiciel mais pourrait être applique à toute science fondée sur la description d’un système. Dans l’immédiat, UML intéresse fortement les spécialistes de l’ingénierie système [9].

Diagramme cas d’utilisation

Description
Acteurs
 Utilisateur « Médecin ou Expert »
 My Expert « System Expert »
 FisPro «Outil d’apprentissage et System Expert »
Pré conditions
1. Installation du JRE (JAVA RUNTIME ENVIREMENT) dans la machine
2. Ajouter FisPro dans la liste des variables d’environnement du system d’exploitation
Buts et perspectives
1. Aide à la décision
2. Satisfaire l’utilisateur du coté lisibilité et efficacité
Ci-dessous est le diagramme de cas d’utilisation de l’application «My Expert »
Figure 9 : diagramme de cas d’utilisation

Cas défaillances et exceptions

1. Fichier invalide (soit .FAI ou .RGL ou .PRJ ou .FIS)
2. La liste de faits | ou règles est vide
3. Faits ou règles déjà existe (ex : Gestion de faits : ajouter un faits qui existe déjà)
4. Faits ou règles n’existe pas (ex : Gestion de faits : supprimer un faits qui n’existe pas)
5. FisPro est Introuvable (n’est pas dans la liste des variables d’environnement)

Etapes d’exécution

1. Gérer un system expert projet
1.1. Gérer la base de faits (+V) [+V => plus Vérification system]
1.1.1. Charger une base de faits
1.1.2. Sauvegarder une base de faits
1.1.3. Ajouter un fait
1.1.4. Renommer un fait
1.1.5. Supprimer un fait
1.2. Gérer la base des règles (+V)
1.2.1. Charger une base de règles
1.2.2. Sauvegarder une base de règles
1.2.3. Ajouter ou supprimer une règle
1.2.4. Ajouter ou supprimer une liste de conséquences d’une règle
1.2.5. Ajouter ou supprimer une liste de faits d’une règle
1.2.6. Supprimer tous les règles
1.3. Faire des recherches et inférences (+V)
1.3.1. Sélection des faits initiaux
1.3.2. Sélection du type de recherche (avant ou arrière)
1.3.3. Le system infère les résultats
1.3.4. Affichage des résultats dans le menu des résultats
2. Charger un projet (+V)
2.1. Gérer un system expert
3. Charger un fichier .FIS (+V) 3.1. Gérer un system expert
4. Lancer FisPro pour faire l’apprentissage (+V)
5. Consulter le fichier Help
2.3. Diagramme de classes
Figure 10 : Diagramme de classes
Description
Ce diagramme représente les classes nécessaires pour assurer un bon fonctionnement du système à mettre en œuvre, le système est composé de plusieurs menu, chaque menu est contenu deux composant essentiel sont la liste des faits, et la List des règles, c’est deux dernier est nul le système est en état élu.
Architecture utilisée
L’idée est de modéliser la base de faits et la base de règles en utilisant une structure algorithmique adaptée qui facilitera la mise en place du moteur d’inférence.
Solution : Représentation sous forme liste chaînées d’objets
Il y a plusieurs façons de représenter les listes chaînées d’objets. L’idée de base est d’utiliser un enchaînement des objets :
– chaque objet (fait ou règle) contient un élément suivant (fait ou règle) dans la liste (Liste Faits ou Liste Règles).
– chaque objet contient une référence vers l’objet suivant, sauf le dernier objet de la liste (qui contient une référence nulle).
– la liste donne l’accès au premier objet (fait ou règle), le reste de la liste est accessible en passant d’objet en objet, suivant leur enchaînement.
Figure 11 : Liste chaînées d’objets

Diagramme de séquence

Pour chaque cas d’utilisation on à spécifier un diagramme de séquence :
1. Cas gérer la base des faits
Figure 12 : Diagramme de séquences (cas gérer la base faits part1)
Figure 13 : Diagramme de séquences (cas gérer la base faits part 2)
Le scénario
Dans le processus de gestions des faits on a l’acteur responsable qui interagie avec le système.
– Pour chaque opération (ajouter, supprimer, renommer) l’utilisateur doit saisir les information essentiel avant de valider l’opération sélectionné.
– Dès que l’utilisateur valide l‘opération, Le système va passé par un test si le faits spécifier par le numéro entré déjà existe, et il va générer des exception en cas de défaillance par exemple :
Ajouter un fait qui déjà existe ou supprimer un fait qui n’existe pas.
Cas gérer la base des règles
Figure 14 : Diagramme de séquences (cas gérer la base règles)

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie ?avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

I N T R O D U C T I O N G E N E R A L E
C H A P I T R E I : G E N E R A L I T E S E T D E F I N I T I O N S
1. Introduction
2. Système d’aide à la décision médicale
3. La typologie des systèmes d’aide à la décision médicale
3.1. Les systèmes d’aide indirecte à la prise de décision ou d’assistance documentaire
3.2. Les systèmes d’alerte ou de rappels automatiques
3.3. Les systèmes consultants
4. Les systèmes experts pour l’aide à la décision médicale
5. Les composants d’un système expert
5.1. Construction d’un système expert
5.1.1. Construction de la base de connaissance
5.2.2. Construction du moteur d’inférence
6. Quelques systèmes experts dans le domaine médical
7. Conclusion :
C H A P I T R E I I : C O N C E P T I O N D ’ A P P L I C A T I O N
1. Introduction
2. La modélisation du point de vue logique
2.1. UML (Unified Modelling language)
2.2. Diagramme cas d’utilisation
2.3. Diagramme de classes
2.4. Diagramme de séquence
3. Conclusion
C H A P I T R E I I I : R E A L I S A T I O N D E L ’ A P P L I C A T I O N MY E X P E R T
1. Introduction
2. Outils utilisés
2.1. Outils de création du design
2.2. Outil de développement AGL :
2.3. Outil de l’apprentissage
3. Les composants GUI de MyExpert
4. Conclusion
C O N C L U S I O N G E N E R A L E
R E F E R E N C E S