3. Spécifications fonctionnelles

Présentation au sujet: "3. Spécifications fonctionnelles"— Transcription de la présentation:

1 3. Spécifications fonctionnelles

2 Spécifications fonctionnelles
Données en entrée 3 types de descripteurs: discrete : données faisant partie d’une liste prédéfinie (ex: « oui », « non », « peut être »); continuous : valeurs numériques ordonnées (ex : IMC); text : phrases ou expressions; « Fast and Furious Decision Tree Induction » est une application générique qui doit pouvoir traiter des données issues de divers domaines (bioinformatique, ensemble de textes, etc.). C’est pourquoi nous allons développer afin de pouvoir traiter trois types d’attributs différents: – discrete : ce qui signifie que les données présentes dans cette colonne devront forcément faire partie d’une liste prédéfinie (ex : oui, non, je ne sais pas), – continuous : valeurs numériques ordonnées (par exemple, dans notre base médicale : l’IMC), – text : ce qui veut dire que les informations présentes dans ces colonnes sont des phrases, des expressions (par exemple : « merci NCMS joël PRENOM collado NPI »est une expression que l’on peut être amené à rencontrer.

3 Spécifications fonctionnelles
Fichiers en entrée 2 fichiers en entrée: .names : la liste des annotations possibles une description du contenu du fichier de données une description du type des descripteurs ou des attributs .data : les données et les annotations associées Grippe, Rhume. age : continuous : ignore. boutons : discrete : cutoff = 15. imc : continuous. L’application recevra les données en entrée sous forme de deux fichiers. Un fichier « .data » contiendra les données et les annotations associées et un fichier « .names » détiendra la liste des annotations possibles et une description du contenu du fichier de données, du type des descripteurs ou des attributs. Nous allons donc décrire plus précisément le contenu de ces deux fichiers. Dans le fichier « .names », la première ligne correspond à la liste de l’ensemble des annotations que l’on peut trouver dans la base de données. Comme dans le premier fichier, chaque annotation est séparée par une virgule et la liste se finit par un point. Nous pourrons trouver ensuite, dans le fichier, une description des colonnes (type, caractéristique). nom_colonne : type_colonne : options_facultatives Le fichier « .data » contient l’ensemble des exemples que l’on veut fournir à l’application. Dans le fichier .data, chaque ligne représente un exemple. (ex: un ligne se décompose de la façon suivante : Age, toux, maux de tête, IMC 1, diagnostic) Les caractéristiques (dans un ordre précis) et l’annotation (unique, et toujours en fin de ligne), sont séparés par des virgules. Un point en fin de ligne permet d’indiquer le fin de l’exemple. Cette syntaxe particulière est importante pour permettre une bonne lecture du fichier en entrée. En effet, l’ordre des caractéristiques, leur type, et leurs particularités sont décrites dans le fichier « .names », il est donc important que le fichier « .data » soit correctement renseigné, afin que chaque colonne puisse être correctement identifiée. 52, Oui, Oui, 25, Grippe. 45, Oui, Non, 28, Rhume. 28, Non, Non, 20, Rhume.

4 Spécifications fonctionnelles
Génération des questions type discrete : 1 question par valeur de l’attribut. type continuous : pour une valeur donnée de l’attribut, la question cherche à déterminer combien d’exemples ont une valeur supérieur ou inférieure à celle-ci. type text : 3 paramètres pris en compte expert_length : nombre de mots à rechercher expert_type : F-gram, S-gram, N-gram expert_level : 3 niveaux de recherche Pour les descripteurs de type discrete, nous générons à partir des exemples, toutes les questions sur la valeur de l’attribut. Pour les descripteurs de type continuous, nous sélectionnons tous les exemples dont l’attribut testé est supérieur ou inférieur à une valeur donnée (ou calculée). Pour les descripteurs de type text, trois paramètres doivent être pris en compte lors de la génération des questions posées par la méthode des arbres de décision : – expert_length : le nombre de mots à dans l’expression à rechercher (ex : parti socialiste = 2 mots). On parle souvent d’expression de longueur N (N étant le nombre de mot), – expert_type : le type de recherche : – F-gram (Full word-grams of maximal length only) : recherche des expressions d’exactement N mots consécutifs (et pas moins, contrairement à N-gram), – N-gram (all full word-grams up to a maximal length) : recherche dans un premier temps, tous les mots un par un de l’expression, puis tous les couples de mots consécutifs et ainsi de suite jusqu’à constituer des ensembles de N (défini précédemment) mots consécutifs, – S-gram (all Sparse word-grams up to a maximal length) : recherche Ngram + recherche des expressions de trois à N mots consécutifs où un ou plusieurs des mots est remplacé par un « blanc » (un mot quelconque). – expert_level : le niveau de recherche : Il existe généralement plusieurs niveaux de recherche. Ils dépendent du type de texte que l’on a, et de la précision de recherche que l’on veut obtenir (par exemple, si on cherche un verbe, est-il important qu’il soit conjugué ?). On peut définir par exemple 3 niveaux. – niveau 1 : recherche des mots exacts dans le texte (ex : "Un incendie s’est déclaré à Paris") – niveau 2 : recherche des natures et fonctions des mots (ex : "Un NOM COMMUN s’est déclaré à VILLE") – niveau 3 : recherche des radicaux des mots, verbes ou noms (ex : "Un incendie s’ETRE DECLARER à Paris")

5 Spécifications fonctionnelles
Données en sortie Format xml Visualisation graphique <? xml v e r s i on =" " e n c o d i n g ="UTF-8" ?> <Tree> <Node id =" 1 "> <Result > < !-- compte-rendu des etiquettes . --> <Result number=“1" name=“grippe" percentage=“50" / > < !– Exemple de resultat --> <Question . . >+ < !-- question qui a amenee a la creation de ce noeud --> <Question column=" Fumeur " value=“oui" e n t r o p y =" 1 " nbOcuurence=" 12 "> < !-- Exemple de question --> <TrueNode id="2" / > <!– noeud où la réponse à la question est “oui” --> <Result...> <Question...> <FalseNode id="3" / > <!-- noeud où la réponse à la question est “non”--> </Node> </Tree> Notre application doit être capable de générer un fichier de sortie utilisable. L’objectif est de rendre un fichier que l’utilisateur pourra consulter : avoir une vision de ce qu’est l’arbre, et pouvoir l’interroger (lui fournir les caractéristiques, et avoir l’étiquette la plus probable). Nous avons donc choisi de représenter notre arbre de décision sous forme d’un fichier XML, format qui nous permettra de définir facilement la structure de nos arbres, créant ainsi un fichier lisible décrivant les résultats et les probabilités d’obtenir ce résultat. Le XML nous permettra d’obtenir en sortie un fichier qui n’est pas « opaque » donc facilement analysable, et surtout utilisable en dehors de l’application. De plus, c’est un format très répandu et utilisé, et donc probablement mieux reconnu et compris par les utilisateurs, et pour lequel il existe beaucoup d’outils. Pour pouvoir naviguer dans l ’arbre, on utilise un id associe a chaque Noeud de l ’arbre.