Projet 4info

Plan Introduction (1min) Contexte du projet (4min) Imadoc, Dmos, EPF, lambda Prolog Etude de l’existant (5min) Présente plugin Eclipse, LPDT et DocReadDT Besoin et spécification (11 min) Visualisation de la grammaire Débogueur DebugDocRead Browser Méthode de développement (2min) Conclusion (2min)

Introduction Recherche de l’équipe IMADOC Reconnaissance de documents Développement d’un Débogueur Contexte complexe Etude de l’existant Présentation de notre solution Ce projet à pour but d’aider les équipes de recherches de l’équipe IMADOC sur leurs travaux concernant la reconnaissance de documents. Plusieurs équipe ont travaillés sur ce sujet, que ce soit dans le cadre stage ou de projet 4info. Nous commencerons par la présentation du contexte dans lequel nous décrirons le fonctionnement d’un système de reconnaissance avec notamment une courte explication sur la méthode DMOS ainsi qu’une présentation des langages EPF et lambda Prolog. Ensuite nous étudierons le fonctionnement du logiciel déjà existant. Enfin nous vous présenterons notre solution afin de répondre aux objectifs du projets.

Méthode DMOS et DMOS-P Description and MOdification of Segmentation I – Contexte du Projet Méthode DMOS et DMOS-P Description and MOdification of Segmentation Description du document par une grammaire EPF Procédé multi-résolution, DMOS-P

Langage EPF Grammaire bidimensionnel I – Contexte du Projet Langage EPF Grammaire bidimensionnel Exemple de reconnaissance d’un rectangle : Point d’ancrage Zone de recherche Opérateur de position

Langage lambda prolog Langage de programmation logique I – Contexte du Projet Langage lambda prolog Langage de programmation logique Extension du langage Prolog Exemple de syntaxe : pere(X,Y) :- parent(X,Y), homme(X). Prédicats Paramètres Faits

Autres fichiers λ-Prolog I – Contexte du Projet Application DocRead 1 fichier EPF 1 fichier λ-Prolog epfc pmc C gcc Autres fichiers λ-Prolog Bibliothèques en C++ Application DocRead Grammaire EPF compilé vers lambda-prolog Fichiers lambda-prolog qui définissent les opérateurs de positions Bibliothèques C++ de traitement d’image et de donnés Le tout génère une exécutable

Résultat après exécution I – Contexte du Projet Application DocRead Exemple de détection des terrains de tennis : Image initiale Résultat après exécution

Etude de l’existant Eclipse : Integrated Development Environment II - Etude de l’existant Etude de l’existant Eclipse : Integrated Development Environment Deux plugins Eclipse conçu par l’équipe IMADOC : LPDT : Gère les fichiers λ-prolog (.pm) DocReadDT : Gère les fichier EPF (.epf) Afin de faciliter le développement de son outil de reconnaissance de documents, l’équipe IMADOC a conçu deux plugins pour l’IDE Eclipse : LPDT qui permet de gérer les fichiers λ-Prolog et DocReadDT qui lui gère les fichiers EPF. Dans cette partie, nous présenterons l’interface de développement Eclipse et plus particulièrement de la façon dont elle est conçue sous forme de plugins. Puis, nous présenterons le plugin LPDT et le plugin DocReadDT à la base du projet puisque notre tâche consistera en son amélioration.

Eclipse IDE (Integrated Development Environment). II - Etude de l’existant Eclipse IDE (Integrated Development Environment). Libre, extensible, universel et polyvalent. Spécificité : architecture en plugins. Eclipse est un environnement de développement intégré (IDE en Anglais) développé par l’Eclipse Foundation. Il est Open Source donc libre et également extensible, universel et polyvalent. Sa spécificité vient du fait que son architecture est développée autour de la notion de plugin.

Eclipse II - Etude de l’existant Vous pouvez voir ici un aperçu d’écran du logiciel Eclipse. On peut voir que l’interface est constitué de différent module que l’on peut déplacer à sa guise. En générale il y a un explorateur de fichier à gauche, un éditeur de fichier au centre, un Outliner à droite et une partie Problème/Console en bas.

Eclipse II - Etude de l’existant On voit ici l’architecture d’Eclipse. On a donc ; Le Platform Runtime qui est le Noyau principal d‘Eclipse. C’est elle qui rend possible l'architecture modulaire d'eclipse. Le Workspace qui gère des fichiers et des répertoire de travail. Après il y a toute la partie graphique avec SWT, JFACE et Workbench. Et enfin il y a le module Help qui gère l’aide et le module team qui permet de travailler en groupe. Par la suites les autres plugins, comme JDT, se branchent sur cet ensemble afin d'utiliser ces fonctions de base tels que l'aide ou la gestion des fichiers.

LPDT II - Etude de l’existant L’équipe Imadoc a donc créer un plugin baptisé LPDT (Abréviation de Lambda Prolog Document Tools) afin de gérer les fichiers λ-Prolog. On peut voir que l'éditeur possède plusieurs zones distinctes. La zone la plus grande est la zone d'édition qui permet d'éditer des fichiers λ-Prolog. Afin de faciliter la compréhension du code, des informations sur un élément sont visibles lors du survol de celui-ci. A gauche celle-ci, on a une zone qui nous permet de naviguer dans les fichiers du projet et à droite une partie outliner qui permet de visualiser les fonctions du fichier en cours d'édition. Tout ceci permet de gagner du temps lors d'une recherche dans le code. En bas, nous pouvons observer une partie console que l'utilisateur pourra utiliser après exécution d'un programme pour voir les traces qu'il aura au préalable laissé dans son code.

DebugLP II - Etude de l’existant Le plugin LPDT possède une deuxième perspectives baptisé DebugLP qui permet, comme son nom l’indique, de débuguer les fichiers λ-Prolog. On peut donc voir que la zone d'édition est réduite par rapport à la perspective LPDT. Concernant le débogage des programmes, une zone de debug située en haut à gauche permet d'arrêter ou d'avancer étape par étape dans un programme en cours d'exécution. A la droite de la zone de debug, une partie est réservée à la visualisation des points d'arrêt et des variables. Ceci nous permet de voir, selon l'onglet activé, les valeurs des variables lors de l'exécution d'un programme ou les différents points d'arrêt mis dans le programme. Tout comme la perspective LPDT la perspective DebugLP possède une zone réservée à la console et une autre pour l’outliner et la navigation mais cette dernière étant moins utile lors de débogage, une place moins importante lui est attribuée. Le dernier module LP Context Stack permet de visualiser la pile des variable.

DocReadDT II - Etude de l’existant DocReadDT est un plugin Eclipse permettant l’édition de grammaire EPF. Il est basé sur le plugin LPDT et il intègre donc de la même manière : un navigateur de fichier, un outliner, une partie console. Il a également un éditeur qui gère en plus les fichiers EPF. Il permet donc de réaliser un analyseur DocRead car il gère à la fois les fichiers .pm (λ-Prolog) et .epf. DocReadDT ne possède pas (encore) de vue de Debug.

Besoin et spécification III - Besoin et spécification Besoin et spécification Visualisation de la grammaire Débogueur DebugDocRead Browser

Besoins Visualiser la grammaire EPF Utilisation d’Xmind III - Besoin et spécification 1 – Visualisation de la grammaire (1) Besoins Visualiser la grammaire EPF Utilisation d’Xmind Nous souhaitons pouvoir générer un arbre, représentable graphiquement, qui nous donnerait une vue d'ensemble de la grammaire en cours de développement. Ceci dans le but de mieux comprendre la grammaire. Remarquons en effet qu'une règle peut contenir une ou plusieurs sous-règles, ce qui rend envisageable la représentation sous forme d'arbre. Nous avons pensé que le modèle sous forme d'arbres proposé par XMind serait une bonne représentation. XMind est un logiciel libre qui permet de créer différents types de diagrammes : des cartes heuristiques, des diagrammes d’Ishikawa (en arrête de poisson), des arbres, des organigrammes, ectetera. De plus, XMind étant une application Eclipse RCP (Rich Client Platform), nous devrions pouvoir facilement l'intégrer au reste du projet. Pour simplifier, on peut dire qu’une application RCP est comme un plugin, sauf que celle-ci peut fonctionner indépendamment d’Éclipse.

Représantation EPF III - Besoin et spécification 1 – Visualisation de la grammaire (2) Représantation EPF Branche dépliée Branche pliée Le langage EPF est composé de plusieurs niveaux. Sur le code de la figure du haut, on voit aisément les différents niveaux. L’exemple traite la reconnaissance de terrain de tennis sur une image. Le niveau 1 est terrainDeTennis, le niveau 2 est composé de Declare, AT_ABS, ZoneService et terrainSimple, etc. De ce fait, celui-ci peut être visualisé sous forme d’une arborescence, à la manière de Xmind. Pour ce faire, il est envisageable de reprendre le code source de Xmind, et d’en réutiliser les fonctionnalités intéressantes de représentation graphique. La grammaire devra également être modifiable avec répercussion sur la représentation. Par contre, la représentation ne sera pas modifiable, seulement explorable. En effet, il devra être possible de déplier les différentes branches pour en voir le contenu, et ainsi explorer les différents niveaux de la grammaire.

Intégration à Eclipse III - Besoin et spécification 1 – Visualisation de la grammaire (3) Intégration à Eclipse On voit ici un aperçu de ce que devra permettre l’ajout de ce module. Nous avons choisi de placer cette visualisation dans la même fenêtre que celle de l’édition des fichiers car il est nécessaire d’avoir un espace suffisamment grand pour afficher les différents arbres. Nous allons donc ajouter deux boutons : ‘Générer arborescence’ qui permettra de scanner le fichier EPF en cours d’édition et d’afficher sa visualisation au format XMind. Ce bouton sera grisé et donc incliquable si la grammaire a déjà été générée, ‘Actualiser arborescence’ qui actualisera l’arbre précédemment créé. L’arbre s’actualisera également lors de la sélection du fichier XMind. L’arborescence pourra être exportée ou non sous format xmind mais elle ne sera pas enregistrée dans un fichier lors de sa génération. Si on ferme le fichier xmind il faudra donc la régénérer.

Spécification Xmind Arbre déplié lors de la génération III - Besoin et spécification 1 – Visualisation de la grammaire (4) Spécification Xmind Arbre déplié lors de la génération Représentation en sous-sujet sous forme d'organigramme bas. Gestion de la récursivité Gestion des règles des grammaires possédants plusieurs définitions L'arbre représentant la grammaire sous XMind sera représenté complètement déplié lors de sa génération. L’utilisateur pourra ensuite aisément replier les branches qui ne l’intéressent pas. L’arbre aura comme sujet central le nom du fichier EPF à visualiser. Il possédera ensuite un sous-sujet correspondant à l’entrée de la grammaire. Celui-ci possédera lui-même des sous-sujets, relatif à sa définition dans la grammaire, qui posséderont eux-mêmes des sous-sujets et cetera. Cela sera modélisé sous forme 'd'organigramme bas' sous XMind. En effet cela correspond le mieux visuellement à une représentation arborescente. De plus cette structure ne prend pas trop de place et permet une utilisation agréable des branches pliables. Le principal problème est qu’une grammaire peut être récursive. Lors de l’analyse du fichier EPF, lorsque l’on détectera une règle de grammaire ayant déjà été développé précédemment dans la branche où l’on se situe, on fera pointer cette règle vers le sous-sujet déjà développé plus haut dans l’arbre. Une règle de grammaire peut posséder une multitude de définitions. Si une règle de grammaire possède plusieurs définitions, on créera un sous-sujet du nom de la grammaire qui possédera lui-même autant de sous-sujets représentants les différentes définitions de la règle. Si elle ne possède qu’une seule définition, on représentera la règle directement par un sous-sujet.

Analyse détaillé Décryptage de la grammaire EPF Restitution sous XMind III - Besoin et spécification 1 – Visualisation de la grammaire (5) Analyse détaillé Décryptage de la grammaire EPF Restitution sous XMind Une des principales difficultés consistera à analyser la grammaire EPF. Nous avons plusieurs outils à notre disposition pour effectuer cette analyse. L’Outliner existant permet déjà de faire la liste des règles de grammaires en les regroupant par noms, si elles possèdent plusieurs définitions, et en affichant leurs paramètres. Une fois ces informations obtenues il faut maintenant les restituer sous XMind. Pour cela on crée un fichier temporaire .xmind auquel on ajoute au fur et à mesure les informations que l’on lit lors du décryptage de la grammaire. Comme on l’a dit, XMind est un logiciel basé sur Eclipse RCP (Rich Client Platform). Il ne devrait donc pas être très difficile d’ajouter un onglet permettant de visualiser le fichier XMind dans Éclipse.

Reprise de DebugLP Même organisation des fenêtres III - Besoin et spécification 2 – Débogueur DebugDocRead (1) Reprise de DebugLP Même organisation des fenêtres Différence entre debugLP et DebugDocRead : Manipulation des variables dans le code EPF Utilisation des points d’arrêts dans le code EPF Création d’une table de correspondance des prédicats

Reprise de DebugLP DebugDocRead: III - Besoin et spécification 2 – Débogueur DebugDocRead (2) Reprise de DebugLP DebugDocRead: meilleure interaction entre code EPF et lambda prolog Inclure image animée si possible

Améliorations des modules existants III - Besoin et spécification 2 – Débogueur DebugDocRead (3) Améliorations des modules existants Onglet Variable Affichage du nom, de la valeur et du type Ajout d’une barre de défilement Identifier les variables de même type Visionner entièrement une variable

Améliorations des modules existants III - Besoin et spécification 2 – Débogueur DebugDocRead (4) Améliorations des modules existants Onglet Editeur Inclusion du fichier Xmind Différenciation des types de fichiers

Modules ajoutés Onglet opérateur de position III - Besoin et spécification 2 – Débogueur DebugDocRead (5) Modules ajoutés Onglet opérateur de position Inclus dans le même module que les variables Même option que pour les variables Distinction de l’opérateur courant

Modules ajoutés Onglet image III - Besoin et spécification 2 – Débogueur DebugDocRead (6) Modules ajoutés Onglet image Interaction avec l’image dans DebugDocRead Changement de la résolution Affichage d’éléments sur l’image

Architecture Débogueur debugDocRead: III - Besoin et spécification Interface graphique Communication avec le programme à débuguer La partie débogage est déjà réalisé par DebugLP

III - Besoin et spécification 3 – Browser (1)

Méthodes développement IV - Méthodes développement Méthodes développement Remplir nos objectifs en 3 parties 2 versions de notre débogueur Développement du Browser en parallèle

Conclusion