Techniques pour l’inférence

Nous avons identifié deux classes de problème : la résolution de con-traintes sur la structure et les domaines de valeur, et la résolution de contraintes de placement géométrique. Sans viser l’exhaustivité, nous présentons les solutions courantes pour ces deux types d’exigences.

2.1. STRUCTURE Les générateurs automatiques d’IHM graphiques de type MB-IDE se

fondent très souvent sur des méthodes ad hoc pour le choix, notam-ment, des interacteurs. [Vanderdonckt 1997] fait une revue de différen-tes approches. Il identifie le type de formulation du système de choix — table de correspondance, règles de production, arbre de sélection, etc.— et la provenance du savoir utilisé — règles ergonomiques, guide de style, règles de conception, etc. Par exemple, le système SEGUIA [Bodart et Vanderdonckt 1994] utilise un arbre de correspondance construit à partir de types simples de données à représenter, de leur domaine de définition et de règles ergonomiques. En sortie, il propose un interacteur appartenant aux boîtes à outils standard (radio-bouton, liste, etc.).

Un système ad hoc est souvent peu extensible, rendant difficile l’ajout de nouvelles contraintes ou règles de production. Pour cette raison,

132

nous optons pour des langages spécialisés en résolution de contraintes comme Prolog ou JESS.

Prolog Prolog, inventé par Alain Colmerauer à Marseille au début des années 70, est un langage de programmation logique avec contraintes. Il en existe de nombreuses implémentations dont Prolog IV [Prolog IV] qui, tout en offrant de bonnes performances, intègre plusieurs résolveurs de contraintes numériques (pouvant couvrir notre deuxième classe de pro-blèmes). Pour des raisons techniques (interopérabilité de Prolog et de Java sur Macintosh, notre plate-forme de développement) nous n’avons pas utilisé cette implémentation.

Il existe d’autres implémentations de Prolog qui peuvent interopérer avec Java, mais nous sommes partis sur le système expert JESS. JESS JESS pour Java Expert System Shell, est la combinaison d’un système

expert et d’un langage de script. Il est entièrement écrit dans le langage Java. Il permet le développement de systèmes experts fondés sur l’expression de règles et d’assertions (faits). Il utilise la même syntaxe que CLIPS [CLIPS]. Nous avons retenu JESS pour trois raisons :

• Il offre de très bonnes performances, supérieures à la plupart des systèmes experts réalisés en C. Cela tient à son moteur d’inférence fondé sur l’algorithme Rete (voir lien [JESS]) qui, par “correspon-dance de formes” (pattern matching) détermine très rapidement les règles pouvant s’appliquer sur un fait donné ;

• Il offre un couplage très fort avec Java. Il a donc été très facile de l’intégrer dans ARTStudio et de faire interopérer les deux systèmes (ARTStudio exécute des commandes sur JESS, JESS appelle des procédures d’ARTStudio, ou crée des objets Java) ;

• Il est ouvert et gratuit.

2.2. PLACEMENT Il existe plusieurs familles de résolution de contraintes géométriques

[Channac 1999][Charman 1995]. Nous rappelons simplement les deux principales approches :

• L’approche algébrique consiste en l’expression des contraintes géométriques sous forme d’équations, puis en la résolution du sys-tème d’équations. Exemple de contraintes : soient trois points A(x_a, y_a), B(x_b, y_b), C(x_c, y_c), et les équations : x_a - x_c = 0, x_b - x_a = 1, y_c - y_b = 0, y_b - y_a = 1; Le placement des points résultera de la résolu-tion des équarésolu-tions.

• L’approche déductive (ou géométrique) consiste en la manipulation symbolique des contraintes géométriques pour créer un modèle géo-métrique concret. Le raisonnement s’appuie sur des règles géomé-triques (ex : AB ⊥ BC et BC ⊥ CD => AB // CD) pour la

133

type : soient trois points A, B, C, tq, AC ⊥ CB, d(AB) = d(CB) = 1, etc.

Dans la première famille, le système d’équations est mis sous forme triangulaire, puis résolu numériquement (voir travaux de [Badros 2000]). Dans la seconde famille, la résolution du problème s’appuie sur des raisonnements faits à l’aide de systèmes experts, de langage de programmation logique, etc. (voir travaux de [Channac 1999]).

Nous sommes partis sur une approche algébrique avec le résolveur de contraintes numériques Cassowary qui s’appuie sur une extension de l’algorithme du simplex : le simplex incrémental [Badros 2000]. Ce moteur offre les avantages suivants :

• Il permet une modification interactive des contraintes, puisqu’il uti-lise une approche par résolution incrémentale (ou propagation de contraintes). A chaque nouvelle contrainte, le système vérifie la vali-dité du système. Ainsi le concepteur peut modifier le modèle de pré-sentation, qui est vérifié dynamiquement par Cassowary ;

• Il est simple à mettre en oeuvre ;

• Il en existe une version Java.

Inversement, ce type de solveur pose le problème de l’incomplétude de la solution trouvée ; il trouve une solution satisfaisant le système d’équation, mais pas toutes les solutions. Notre problème étant sous-contraint — plusieurs placements d’interacteur peuvent être valides pour une même IHM (pour le même modèle de présentation), il existe plusieurs solutions. Or celle trouvée par le solveur peut ne pas satis-faire le concepteur. Comme le concepteur ne peut pas ou ne sait pas exprimer³ suffisamment de contraintes pour que le solveur trouve la solution qu’il aimerait avoir, jamais elle ne lui sera proposée.

Pour répondre à ce problème, il faudrait coupler ce résolveur avec un langage qui énumérerait toutes les solutions (c’est ce qui est fait en Prolog par exemple). Dans notre cas, il aurait fallu regrouper JESS et Cassowary, ou revenir sur un système du type Prolog IV.

3. Des contraintes ergonomiques ou artistiques, un savoir faire en graphisme, ne sont pas nécessairement exprimables sous la forme d’équation.

134

3. Squelette du dialogue : génération de