Un prototype opérationnel à évaluer

Le modèle de synthèse proposé au Chapitre 3 a été abordé ici d'un point de vue opérationnel, permettant la mise en place d'un prototype. Ce prototype a été conçu selon une architecture logique reétant les fonctionnalités nécessaires à la réalisation d'un document de synthèse telle qu'une gestion des utilisateurs, une saisie de requête structurée, une instanciation de tâche guidée par la requête, une exécution d'instance de tâche et une présentation du document nal.

Ancrée dans un cadre de développement spécique, cette architecture a induit des choix technologiques particuliers. Le contexte du projet TMA-Explorer a con-duit au choix d'une architecture Web trois-tiers, d'un développement en JAVA et du stockage du corpus documentaire au sein d'une base de données. Les besoins

de réutilisation de données des usagers potentiels ont suggéré le recours massif au format XML pour représenter les entités impliquées dans le processus de synthèse. Un choix personnel de simplicité de conception et développement a requis la mise en place d'un framework composants spécique, où les composants communiquent par l'intermédiaire d'un tableau noir, pour implémenter des méthodes de résolution pour chaque sous-tâche élémentaire d'un modèle de tâche.

Une fois mis en place ce cadre de développement, les entités principales impliquées dans le processus de synthèse, c'est-à-dire les notions de tâche et de connaissances applicatives, ont été présentées d'un point de vue implantation. Les diverses fonction-nalités du prototype ont aussi été présentées, conjointement aux choix de développe-ment associés.

En pratique, un système d'assistance à la synthèse a donc été mis en place. Par rapport aux bases conceptuelles qui ont été décrites au Chapitre3, le développement du prototype a en général conduit à une simplication des problématiques sous-jacentes identiées au chapitre précédent et à une limitation du champ couvert par le prototype.

Cette simplication a tout d'abord concerné le niveau de ranement pris en compte dans les diverses entités et processus. Par exemple, au niveau gestion des utilisateurs, la notion d'archétype a été laissée de côté. De plus, la prise en compte de connaissances expérimentales de type méthodes, qui inuencent la résolution d'une sous-tâche élémentaire, est restée naïve. De même, le choix d'une source de spécialisation pour une sous-tâche est réalisé selon des heuristiques très simples, par un arbre de décision gé a priori.

Cette simplication est aussi intervenue selon une dimension résolution de prob-lème. Certaines sous-tâches élémentaires sont fonctionnellement très complexes, sans être facilement décomposables plus avant en problèmes unitaires de petite taille. La résolution de tels problèmes a en général été proposée par des méthodes parfois simplistes, conduisant à une résolution qui est loin d'être optimale.

Par exemple, au sein des tâches prototypiques de type comparaison, une tâche élémentaire calcule l'attribution de zones de la grille à chaque groupe et sous-groupe dénis précédemment. Il s'agit d'un problème très complexe, similaire au problème de bin packing, classique en Recherche Opérationnelle, mais avec des formes de boîtes dynamiques, à surface plus ou moins constante. Il a été résolu de manière rudimentaire, conduisant dans certains cas à un usage non optimal de l'espace disponible.

De plus, le champ couvert par le prototype a aussi été limité. Cette limitation est intervenue selon deux axes : le corpus documentaire et les tâches prototypiques.

concepts quantitatifs et qualitatifs des connaissances du domaine ont été pris en compte. Ceci a permis d'éviter de démultiplier les traitements en fonction de la nature des éléments manipulés. De plus, les problématiques complexes relevant de la Recherche d'Information en tant que telle ont pu être laissées de côté. La taille des documents a aussi été limitée : seuls les éléments jugés par les utilisateurs comme vraiment essentiels ont été pris en compte.

Au niveau des tâches prototypiques, seules deux tâches ont fait l'objet de la déni-tion d'un modèle de tâche et du développement des composants correspondants, an de réduire le nombre de composants à développer. Les tâches de comparaison sont représentées par la tâche prototypique de comparaison d'une variable entre plusieurs groupes, où les éléments de la comparaison sont dénis par l'usager, qui a servi d'ex-emple dans ce chapitre et le précédent. Les tâches d'évolution sont représentées par une évolution monovariée.

Au nal, malgré ces simplications et limites, un prototype fonctionnel est disponible. Se pose alors la question de l'adéquation du logiciel développé au modèle de synthèse de données envisagé et surtout au besoin d'appréhension de données qui a été identié. Ceci implique de s'intéresser à une validation expérimentale du prototype, objet du prochain chapitre.

Fig. 4.14: Aperçu d'un document de synthèse - La grille documentaire donne accès à une che patient qui présente le dossier clinique et une liste de données histologiques associées. Chaque

Fig. 4.15: Principe de la transformation du document maître - Ce schéma montre comment l'application des règles XSLT du modèle de présentation transforment le document maître en document de synthèse. Ainsi, les traits ns de divers types montrent comment chaque Ligne du document maître devient une ligne (ou zone rectangulaire horizontale) du document de synthèse. Les èches à pointe ne correspondent à la transformation des groupes en zones rectangulaires