4.4. Mise en application
4.4.1 Module de fouille de données
4.4.1.2 Phase d’élaboration
La phase d’élaboration permet de spécifier, analyser et concevoir la plupart des cas d’utilisation. C’est une phase qui s’est déroulée en trois
itérations. Dans chaque itération, nous avons présenté les nouveaux cas d’utilisation, l’analyse de ces cas ainsi que la conception de ceux qui sont
déjà analysés dans l’itération en cours ou dans les itérations précédentes.
Tableau 4.2 : déroulement de la phase d’élaboration pour le module de fouille de données
Activités Itération 1 Itération 2 Itération 3
Capture des besoins
Analyse des situations décisionnelles
Nous avons commencé par une étude des travaux internationaux et nationaux réalisés sur la technique des RBD, surtout en ce qui concerne la classification.
En fait, pour pouvoir appliquer une classification dynamique d’un nouveau cas de prédiction, il faut tout d’abord l’ajouter dans la base de données préparée.
Sans objet dans cette itération Sans objet dans cette itération
Élaboration des premières maquettes d’IHM
Une maquette papier a été réalisée par l’expert ECD lors d’une réunion de capture des besoins pour expliquer le déroulement de la classification dynamique.
L’utilisateur a proposé une maquette papier présentant des options de navigation dans l’IHM de classification dynamique.
Aucun changement au niveau de l'architecture initiale des IHM proposées.
Modélisation de l’utilisateur
L'utilisateur a bien compris le principe de l’ExUP. Il trouve avantageux de pouvoir exprimer d'autres besoins et proposer des modifications au cours du déroulement du projet (acteur d'une démarche participative).
Expression des besoins décisionnels
Après la compréhension du principe du cas d’utilisation de classification dynamique, on a pu le raffiner en ajoutant un nouveau cas d’utilisation : ajout d’un cas de prédiction dynamique
Aucun changement au niveau du diagramme de
cas d’utilisation. Sans objet dans cette itération
Evaluation des besoins
Les utilisateurs ont évalué le diagramme de cas d’utilisation raffiné. Ils ont trouvé que les fonctionnalités du module répondent mieux aux besoins de la fouille des données.
Sans objet dans cette itération
Les nouveaux besoins exprimés par le diagramme de cas d’utilisation et la documentation associée sont présentés à l’utilisateur dans un but d’évaluation.
Le résultat d’évaluation est satisfaisant. Répartition et définition des
tâches
Une nouvelle tâche est définie dans ce niveau de conception. C’est la tâche d’ajout de cas de prédiction dynamique.
En se basant sur la maquette papier proposée, on dégage deux nouvelles tâches interactives (cf. ci-dessous).
Sans objet dans cette itération
Définition des tâches
manuelles Sans objet dans cette itération Sans objet dans cette itération Sans objet dans cette itération
Définition des tâches
automatiques Sans objet dans cette itération Sans objet dans cette itération Sans objet dans cette itération
Définition des tâches interactives
La tâche d’ajout de cas de prédiction dynamique est une tâche interactive nécessitant l’intervention de l’utilisateur lors de son exécution.
Ajout des deux tâches suivantes :
Ajout de "Jour Suivant" et "Jour Précédent". La saisie de la date au clavier reste toujours possible.
Lorsque l'utilisateur saisit un nom ou un index (code administratif), le ou les patients concernés(s) sont affiché(s).
Sans objet dans cette itération
Evaluation des tâches L’utilisateur a détaillé certains points pour une meilleure analyse et conception de ces tâches.
L’utilisateur a trouvé que le concepteur a bien compris sa maquette papier.
Analyse et conception
Spécification des tâches automatiques
Analyse du cas d’utilisation d’ajout d’un nouveau cas (patient) pour une future classification dynamique.
On a utilisé les diagrammes de communication et d’activités pour l’étape de spécification.
Analyse des tâches automatiques de classification dynamique d’un cas de prédiction.
Analyse du cas d’utilisation d’ajout d’un cas d’apprentissage.
Spécification des tâches interactives
Analyse des tâches de choix des informations
relatives au patient à classifier. Sans objet dans cette itération Sans objet dans cette itération
Spécification des IHM Spécification des IHM d’ajout d’un cas de classification dynamique.
C’est la même IHM que pour la tâche d’ajout
d’un cas de classification dynamique. Sans objet dans cette itération
Conception des modules automatiques d’ECD
Conception du cas d’utilisation d’ajout d’un cas de classification dynamique dans les différents scénarios.
On a utilisé les diagrammes de séquence pour l’étape de conception.
Conception des tâches automatiques de classification dynamique d’un cas de prédiction.
Conception du cas d’utilisation d’ajout d’un cas d’apprentissage dans les différents scénarios (succès et échec).
Conception des IHM et des modules interactifs d’ECD
Conception de l’IHM d’ajout d’un cas de classification dynamique.
C’est la même IHM que pour la tâche d’ajout
d’un cas de classification dynamique. Sans objet dans cette itération
Evaluation des modèles
Les diagrammes de communication et de séquence ont été évalués par les utilisateurs pour vérifier si les concepteurs ont bien compris les besoins.
Résultat satisfaisant.
Les diagrammes UML de communication et de séquence ont été évalués par l’équipe de développement pour passer à l’implémentation des tâches de classification dynamique.
Sans objet dans cette itération
Elaboration des maquettes avancées d’IHM
Une maquette électronique de classification dynamique a été préparée pour traduire les besoins utilisateurs.
Sans objet dans cette itération Sans objet dans cette itération
Spécification de l’architecture
En se basant sur les modèles et les maquettes, on a pu définir l’architecture initiale de module de fouille de données.
L’architecture spécifiée dans l’itération
précédente est légèrement modifiée. Sans objet dans cette itération
Evaluation de l’architecture
L’architecture est composé des IHM et modules fonctionnels de classification dynamique. L’utilisateur a évalué cette architecture et a montré sa satisfaction de cette première vision du module.
Une re-évaluation de l’architecture de module en cours de réalisation.
Résultat : satisfaction du module.
Avec les nouvelles informations, l’architecture du futur système commence à s’enrichir.
Implémentation
Codage des fonctionnalités Sans objet dans cette itération Notre SIADDM/ECD fonctionne sur les données temporelles. La base des données
Codage de la fonctionnalité d’ajout d’un cas de prédiction dynamique
temporelles a déjà été prétraitée lors des travaux antérieurs et implémentée sous SQL server. Donc il nous reste à implémenter la technique des Réseaux Bayésiens Dynamiques. Pour se faire nous avons utilisé le langage de programmation C#. net.
Le codage des fonctionnalités se fait dans un fichier cs (fichier écrit en CSHARP)
Codage des Interfaces
Homme-Machine Sans objet dans cette itération
Le codage des IHM se fait dans un fichier resx (RESource file eXtension)
Préparation de l’IHM d’ajout d’un cas de prédiction dynamique.
Construction du prototype Sans objet dans cette itération
Pour exécuter une fonctionnalité sous C#, il faut assembler le fichier cs et celui resx.
Assembler le fichier cs et celui resx d’ajout d’un cas de prédiction dynamique.
Le premier prototype de ce module permet un ajout d’un nouveau cas (patient) pour une future classification dynamique
Test
Sans objet dans cette phase