• Aucun résultat trouvé

Formalisation des propriétés requises du module d’interprétation de

6.2 Formalisation d’un module de référence

6.2.2 Formalisation des propriétés requises du module d’interprétation de

Nous allons à présent utiliser le formalisme introduit précédemment pour formaliser les caractéristiques qu’un module d’interprétation de page doit posséder pour permettre l’inté- gration d’un mécanisme d’interprétation itératif à l’aide de la mémoire visuelle. L’identifi- cation de ces éléments est importante pour permettre de définir une classe de programmes qui pourront être facilement modifiés pour intégrer nos propositions. Dans notre cas, cela revient à décrire rapidement quelles sont les instructions de ces programmes, quel est l’en- vironnement qui peut être modifié (et dont le contenu définit l’état du programme), et quel est le flot de contrôle général de ces derniers.

Il est important de noter que le type de module d’interprétation de page que nous pro- posons de transformer (et que nous décrivons ici) est basé sur une recherche descendante, en profondeur d’abord, d’une solution dans l’espace associé. Toutefois, les éléments de syntaxe restent généraux et pourront être adaptés.

6.2.2.1 Syntaxe

Le langage de description de page que nous proposons de considérer est une extension simple, à deux dimensions, de l’exemple de la sous-section 6.2.1. Pour les éléments de langage suivants, nous pourrons distinger deux sortes de constructions :

– les structures de contrôle, qui permettent de construire le programme ;

– les opérateurs, dont l’utilisation peut avoir des effets de bord sur le programme, et qui peuvent retourner une valeur.

Nous préciserons les types des paramètres et résultats des opérateurs et des expressions lorsque c’est nécessaire, pour le domaine de représentation de la description (le typage des éléments compilés sera différent).

Alternative

Notation : A | B

Type :sans (structure de contrôle)

Comme dans l’exemple précédent(page97), cette construction indique la possibilité de reconnaître A ou B.

Concaténation Notation : A B

Type :sans (structure de contrôle)

Comme dans l’exemple précédent (page97), cette construction indique la nécessité de reconnaître A puis B.

Positionnement Notation :@P Type :Zone → ()

Cet opérateur de positionnement @ permet de définir une zone de recherche avec la valeur de P pour la suite des calculs, et rappelle la syntaxe des grammaires de position. P est donc une expression dont la valeur est de type Zone.

Élément terminal Notation : term(T )

Type :TypeDonnée → DonnéeImage

La modification de l’accès aux éléments terminaux est utile pour récupérer une don- née image (zone et type) d’un type précis contenue dans la zone de recherche. Passer

le type en paramètre de cet opérateur permet de simplifier la gestion du nombre réduit d’éléments primitifs de l’image décrits par leur type : trait, composante connexe, etc. Dérivation

Notation : G −→ D

Type :sans (structure de contrôle)

Comme dans l’exemple précédent(page97), cette construction indique l’abstraction de la construction complexe D avec le non-terminal G. Cette construction permet d’indiquer que G est du type de D, si un résultat est retourné.

6.2.2.2 Structures de données

Les structures de données nécessaires au programme d’interprétation sont les suivantes. Structure image notée I dans la suite, cette structure est un ensemble de couples de type (Zone, TypeDonnée) où les éléments de type TypeDonnée peuvent être « segment », « cercle », ou encore « composante_connexe ». Cette structure est initialisée au lancement du programme avec des détecteurs9spécialisés dans la génération de dif-

férents symboles, que nous ne présenterons pas.

Zone de recherche notée R dans la suite, cette zone permet de focaliser l’interprétation sur une partie de l’image. Elle est de type Zone mais pourrait être beaucoup plus complexe.

Mémoire Visuelle notée M dans la suite, nous ajoutons d’emblée cette structure dans la sémantique du programme pour simplifier la présentation des opérations sur la mé- moire de lasous-section 6.2.3. Cette structure est composée d’un couple de calques (MT, MC) contenant chacun des triplets du type (Zone, TypeDonnée, Informations).

Autres structures Le programme de référence que nous proposons de transformer utilise déjà certaines structures de données pour stocker son état. Ces dernières devront être conservées. Nous introduisons donc une structure ε qui portera cette information non spécifiée à ce niveau.

Continuations Afin de permettre une exploration guidée par le but, en profondeur d’abord, de l’espace des solutions, la gestion du retour arrière qui sera représenté par des conti- nuations de succès κ et d’échec ζ dans la suite.

6.2.2.3 Compilation et sémantique du programme

Pour un module d’interprétation de page dont le programme est : – basé sur une analyse symbolique du contenu ;

– guidé par le but ;

– et explorant l’espace de solution en profondeur d’abord ;

le système de traduction de la description vers les fonctions exécutables peut être spécifié de la façon suivante, largement inspirée de l’exemple de lasous-section 6.2.1.

9. Ces détecteurs sont, à l’instar de l’analyse lexicale pour l’analyse syntaxique en compilation classique, un préalable indispensable à l’interprétation symbolique d’images.

T

[[A | B]] ≡ λ εRIMκζ.(

T

[[A]] ε R I M κ (

T

[[B]] ε R I M κ ζ))

T

[[A B]] ≡ λ εRIMκζ.(

T

[[A]] ε R I M

λ ε′R′IM.(

T

[[B]] εRIMκ ζ) ζ)

T

[[@P]] ≡ λ εRIMκζ.(κ ε [[P]] I M)

T

[[term(T )]] ≡ λ εRIMκζ.         

(κ e ε R (I \ e) M) si (∃e = (zone, type) ∈ I ∧type = T

∧zone ∩ R 6= /0)

ζ sinon

T

[[G]]

T

[[D]] si G −→ D

(6.15) Par rapport à l’exemple de l’équation 6.13, on peut constater que les règles de réécriture pour l’alternative, la concaténation et la dérivation restent quasiment inchangées : elles se contentent de faire circuler un contexte plus riche. Les modifications les plus importantes sont liées à la gestion du caractère bidimensionnel de la structure à interpréter, à savoir :

1. la possibilité de définir une zone de recherche R avec la valeur de P lors de l’appel à l’opérateur de positionnement @P ;

2. la validation du type et de la position d’un élément terminal, puis sa consommation de la structure image I lors de l’appel à l’opérateur d’accès aux terminaux term(T ). On peut remarquer dans les règles de l’équation 6.15que la circulation des paramètres dépend de leur nature, et on peut en distinguer deux types :

1. ceux qui sont transformés lors des étapes de la reconnaissance, tels que ε, R, I ou M, et se propagent « horizontalement », c’est à dire d’instruction en instruction ;

2. ceux comme κ et ζ, qui sont propagés « verticalement » et construits par les structures de contrôle qui leur donnent une portée, et qui sont utilisés par les opérateurs. 6.2.2.4 Exemple de description

Dans ce type de système, la gestion de variables (déclaration d’identifiants, affectation, et lecture) est relativement simple à mettre en œuvre en gérant un nouveau paramètre qui associerait à chaque identifiant défini (dans le bloc courant) un emplacement mémoire.

On peut alors écrire des descriptions de la forme de l’exemple ci-après, dans lequel on cherche (naïvement) à détecter un rectangle et calculer son aire :

rectangle −→ var cote1 cote2 cote3 cote4 @une_zone cote1 ← term(trait_horizal) @(droite cote1) cote2 ← term(trait_vertical) @(bas cote2) cote3 ← term(trait_horizal) @(gauche cote3) cote4 ← term(trait_vertical)

renvoyer (calculer_aire cote1 cote2 cote3 cote4)

Dans la description précédente, le concepteur a, bien entendu, dû définir les fonctions droite, bas, gauche, calculer_aire, mais on peut supposer que certains éléments soient déjà définis, comme par exemples trait_horizal et trait_horizal du type TypeDonnée.

Ce type de description permet la génération automatique d’un programme d’interpré- tation d’image à partir d’une description proche d’une grammaire attribuée. Toutefois, ce n’est pas complètement suffisant pour définir un module d’interprétation de page : il faut aussi être capable d’extraire les primitives visuelles de l’image, charger le contenu de la mémoire visuelle en début d’analyse et le sauvegarder à la fin, renvoyer l’état terminal du programme au module de stratégie globale, etc.

Nous montrons rapidement dans lasous-section suivantecomment gérer l’intégration de la mémoire visuelle, et ne ferons pas plus de suppositions à propos du fonctionnement d’un éventuel système à adapter.