Création d’application : défi sportif

Pour cette application, plus complexe que la précédente, nous n’allons pas redonner le code source entier de l’application mais nous allons donner quelques extraits permettant de montrer la difficulté qu’il y a à maintenir un code synchronisé lorsque l’on écrit des scripts spécifiques à l’application.

Le principe de cette application est de proposer un duel entre l’utilisateur et l’ordinateur fondé sur un pari. Pour garder une certaine lisibilité, nous reprécisons les règles qui avaient été données dans la Table 9, p63.

L’utilisateur dispose de quatre sports différents dans lesquels il doit se définir une maîtrise particulière. Cette maîtrise se matérialise par l’attribution d’un certain nombre de points dans un sport particulier. La valeur attribuée dans un sport est un pourcentage exprimant la probabilité qu’a l’utilisateur à réussir un coup ou une manche dans ce sport (exemple : 75 en tennis indique qu’on à 75% de chance de réussir un coup au tennis).

Au début du jeu, l’utilisateur se voit attribuer un total de points à répartir entre les différents sports. A lui de choisir une stratégie d’attribution des points sachant que l’ordinateur fait la même chose en parallèle, mais le score que l’ordinateur choisit est caché au joueur.

Lorsque le joueur a fini de répartir ses points, la partie commence et le joueur peut défier l’ordinateur sur un sport, celui-ci de son côté va choisir le sport avec lequel il relèvera le défi. Une série de trois manches est jouée et celui qui aura remportée une majorité de manches sera déclaré vainqueur. Cette démarche est répétée jusqu'à ce que tous les sports aient été utilisés.

Table 17 : règles du jeu de l’application du Jeu du Défi

Afin d’illustrer la capacité qu’a l’agent conversationnel de traiter une requête, suivons le déroulement du traitement d’une requête entrée par l’utilisateur :

L’utilisateur a entré la requête : « à quoi sert le curseur ? stp ». Pour construire la requête formelle DAFT, l’entrée de l’utilisateur est confrontée à un patron sémantique de la forme :

< <SPEECH ACT> <PREDICAT> <REFERENCE* > >

Ce qui permet d’extraire de la requête les informations sémantiques pertinentes. Dans notre exemple, le résultat de l’étage de traitement de la Langue Naturelle a renvoyé la requête formelle :

« <<ASK> <USAGE> <REF[Sbest , Qcursor]]>> »

Le résultat du traitement de cette requête formelle produit une réponse multimodale de l’agent : objet mis en surbrillance, phrase qui s’affiche et/ou qui est donnée en synthèse de parole, … en même temps que dans le modèle, on montre en surlignant l’objet correspondant.

Figure 27 : capture d’écran de l’application Jeu du Duel avec la réponse de l’agent à une requête.

Pour donner un ordre d’idée, le modèle de la première application comporte 13 lignes de codes, la partie scripts spécifiques comporte 25 lignes de code, ce qui représente un ratio de l’ordre de 2.

A titre de comparaison, le modèle de la deuxième application comporte 21 lignes de codes (ce qui n’est pas une augmentation significative, vu que la première application comprenait 6 Widgets et que la deuxième en comporte 4 fois plus). La partie de scripts spécifiques comporte, elle, une centaine de lignes de code, soit cinq fois plus (voir Table 18).

5.3 - Evaluation Nom de l’applica-tion : Nombre de lignes de code : Nombre de lignes de code de la partie « scripts spécifiques » Rapport scripts spécifiques / lignes de code Nombre de Widgets : CD-thèque 13 25 2 6

Jeu du Duel 21 100aine 24

Table 18 : Comparaison des caractéristiques structurales de l’application « CD-thèque » avec celles de

l’application « Jeu du Duel ».

Le concepteur de l’application se retrouve donc à écrire un nombre considérable d’instructions en plus de l’écriture du modèle, celui-ci ne permettant pas d’anticiper les différentes opérations nécessaires au déroulement du jeu. Prenons un exemple simple : avant de commencer un match, il faut vérifier la validité de la répartition des points, donc lire le contenu de tous les Widgets de type « zone de texte » contenant la valeur attribuée au sport.

§TRIALbuttonincrscript[s_,tf_,spl_,bminus_]:=Module[{}, (* mise a jour du modele *)

If[s[VAL]<maxpointsperskill, skillpointsleft=skillpointsleft-5; s[VAL]=s[VAL]+5; tf[TEXT]=ToString[s[VAL]]; bminus[VAL]=s[VAL]; spl[TEXT]=ToString[skillpointsleft]; §LEAgui @ InvokeMethod[{tf[JREF], "setText"},ToString[tf[TEXT]]]; §LEAgui @ InvokeMethod[{spl[JREF], "setText"}, ToString[skillpointsleft]]; ] …

Code source 16 : exemple de script (extrait).

De plus, nous sommes en présence d’une entité « skill » virtuellement composée de quatre Widgets différents (bouton ‘+’, bouton ‘-‘, label « skill 1 », textfield) et une action pour augmenter la valeur du champ demande de toucher au modèle de quatre

composants différents, ce qui n’est évidemment pas prévu dans le modèle générique proposé. Voici l’extrait de code permettant de traiter l’augmentation d’une valeur : Les méthodes génériques n’existant pas, le concepteur de l’application est obligé de modifier directement le composant (les quatre lignes en gras dans le Code source 16). Il suffirait de rajouter des méthodes génériques mais, si l’exemple présenté est trivial (il semblerait normal qu’un objet possédant une valeur dispose d’une méthode pour mettre à jour cette valeur), on peut concevoir que dans des applications plus complexes le concepteur ait besoin de méthodes spécifiques qu’il n’est pas possible d’anticiper au moment de l’écriture du modèle du composant.

5.4 Conclusion

L’implémentation de Daft-Swing permet de fournir une liste de composants utilisables pour construire des modèles d’application. Ces modèles d’application permettent de générer une application minimalement fonctionnelle mais dont l’IHM est complète et utilisable.

Plusieurs points sont particulièrement importants à mentionner :

- Caractère générique de la modélisation : un modèle fondé sur des Widgets est intéressant, toutefois il ne permet pas de capturer l’ensemble des fonctionnalités de manière précise. En effet, à l’issue des développements, pour représenter des comportements complexes dans une application, il était nécessaire de rajouter des scripts supplémentaires. Ces scripts sont rédigés dans un langage expert qu’il est nécessaire de maîtriser avant de pouvoir le mettre en œuvre. Il s’agit d’une limitation importante de la généricité.

L’apport est malgré tout important car la librairie de composants reste indépendante pour la description graphique d’une application. Or, il s’agit d’un élément communément partagé par la plupart des applications qui utilisent le même langage graphique (le paradigme WIMP). Les composants que nous avons développés intègrent des éléments liés au traitement de l’assistance et des références de l’utilisateur : dans l’absolu, un développeur peut les manipuler sans savoir comment ils sont implémentés : l’application, ou le site qu’il aura créé ne demandera aucune manipulation supplémentaire pour qu’un ACA puisse y avoir accès, même de façon sommaire.

- Parti pris perceptuel : les développements effectués ont été satisfaisants d’un point de vue logiciel, du fait de la disponibilité de la bibliothèque d’objets et de son insertion dans l’architecture générale du projet Daft. Toutefois les éléments programmés n’ont pas permis de mettre en évidence un avantage particulier à privilégier une représentation par les Widgets, et par extension, une représentation guidée par la perception.

D’une certaine manière, la situation est plus problématique : les différents éléments en rapport avec le fossé cognitif dont nous avons discuté au cours des chapitres 3 et 4 notamment, se sont également retrouvés dans nos modélisations, en particulier, le

5.4 - Conclusion

traitement des références à des éléments qui ne sont pas explicités dans la modélisation mais pour lesquels l’utilisateur semble avoir une représentation.

En conséquence de ces deux éléments, nous avons proposé des ouvertures permettant de prendre en compte ces différentes limitations de Daft-Swing.

L’étude de la généricité se poursuit sur le développement d’outils permettant de synthétiser des modèles Daft-Swing mais en masquant leur provenance. Daft-Swing proposant de créer des applications à partir des modèles, nous allons explorer la problématique inverse : de créer des modèles à partir de sources de connaissances, telles que nous les avons définies au chapitre 3. En l’occurrence, nous traiterons du code source dans le chapitre 6 et d’un opérateur humain dans le chapitre 7.

Par ailleurs, le développement d’outils pour la synthèse de modèle fournira le cadre pour poursuivre nos réflexions sur la pertinence et la faisabilité d’une modélisation axée sur la prise en compte de la perception de l’utilisateur. Cette réflexion se fera par le biais de l’étude des agrégats de composants, ce qui permet de prendre en compte une partie des phénomènes qui échappent aux modèles non orientés vers l’assistance : la création d’artefacts mentaux chez l’utilisateur qui ne trouvent aucune contrepartie dans un modèle.

6 DOM-Filter : de l’application au

modèle

Nous avons identifié au chapitre 3, p51 plusieurs sources de connaissances : l’utilisateur, le concepteur, l’application elle-même et la documentation externe. La question principale qui va nous préoccuper est de savoir s’il est possible de constituer un modèle générique à partir de ces sources hétérogènes. Cette question est traitée au travers de la problématique du regroupement perceptuel.

On pose comme hypothèse qu’il est possible d’obtenir un modèle de l’application, fondé sur des indices perceptuels, qui puisse être une représentation intermédiaire entre l’agent et l’application. Nous étudierons la question au travers de deux études de cas. La première, présentée dans ce chapitre, traite de l’usage du code source des applications comme source de connaissances. Le chapitre suivant traite le cas complémentaire où un opérateur humain est utilisé comme source de connaissances.

Ce chapitre est décomposé en trois parties. Dans la première partie, nous présentons l’algorithme de regroupement perceptuel. Dans la deuxième partie, nous présenterons brièvement quelques technologies en usage actuellement et qui sont également utilisées dans la suite du développement. Dans la dernière partie, nous présentons l’outil logiciel DOM-Filter qui met en œuvre l’algorithme. Il est illustré sur une étude de cas (la page d’accueil d’un moteur de recherche).

D’un point de vue méthodologique, il est important de préciser que ces deux études de cas sont liées. Pour évaluer la pertinence de la démarche, c’est le même algorithme de regroupement qui est employé dans les deux études de cas.