Implémentation de Kiwi

Le cœur de la plate-forme Kiwi réside dans son implémentation client. Nous allons nous intéresser plus spécifiquement aux possibilités offertes par la plate-forme en détaillant deux aspects importants :

- La gestion des interactions avec l’utilisateur : on s’intéressera à la façon dont est mise en œuvre la construction d’une application par un opérateur humain.

- La construction d’un modèle : on s’intéressera à la façon dont est intégré et implémenté l’algorithme perceptuel et quel est le modèle de données utilisé pour stocker les informations ainsi que les résultats obtenus.

7.3.3.1 Interaction avec l’utilisateur

A. L’interface en général

L’interface de la plate-forme Kiwi est très simple (cf Figure 44) et reprend les standards des éditeurs WYSIWYG classiques.

La zone de conception est matérialisée par un large rectangle agrémenté d’onglets. Chacun des onglets représente un axe particulier de la conception. On en dénombre actuellement trois :

- Layout view : dans cette zone, l’utilisateur peut concevoir l’interface graphique de l’application. Le layout est le terme utilisé dans le développement d’interfaces graphiques pour désigner le mode de disposition des composants dans la zone d’affichage. En Java, par exemple, on trouve le GridLayout qui permet de répartir les composants dans une grille. Le terme a été conservé dans nos développements, car il s’agit de laisser à l’utilisateur le soin de définir la disposition des composants ;

- Func view : dans cette zone, l’utilisateur peut ‘scripter’ le comportement de l’application et relier les composants graphiques avec des actions ;

- Annotation view : dans cette zone, l’utilisateur entre dans le mode d’annotation de l’application. Il peut choisir soit de désigner des éléments, soit de valider des éléments en provenance de l’algorithme perceptuel.

Figure 44 : capture d’écran de l’environnement Kiwi. Sur l’écran on peut voir les éléments suivants : en

1, la boîte flottante de sélection des Widgets ; en 2, la zone de création représentant le contour de la future application ; en 3, les onglets permettant de passer d’une vue à une autre – la quatrième vue est optionnelle, elle permet d’afficher une vue du modèle tel qu’il est calculé par Daft ; en 4, la boîte de dialogue permettant de dialoguer avec l’environnement Daft – cette boîte permet notamment de transmettre des commandes en langage Daft, permettant de tester en temps réel des requêtes utilisateurs ; en 5, la zone de suppression des Widgets, représentée par une corbeille.

Le développement complet de Kiwi fait appel aux modules suivants :

- Librairie de Drag And Drop et gestion de la disposition des Widgets (cf paragraphe B)

- Modèle objet de l’environnement Kiwi (cf paragraphe C) - Gestion de la définition des fonctions (cf paragraphe D) - Protocole de communication client/serveur (cf. paragraphe E) Nous allons détailler chacun de ces aspects dans les paragraphes suivants.

1 2

3

4

7.3 - Description de la Plate-forme Kiwi

B. Layout view

Nous exposons plus précisément les interactions disponibles dans ce mode d’édition. L’interaction privilégiée est simple : dans l’absolu, l’outil se destine à des utilisateurs, il faut donc garder la simplicité comme principe dans le développement (KISS : Keep It Small and Simple).

En l’occurrence, l’interaction principale se fait à la souris, par glisser/déposer. Une librairie en JavaScript a été développée pour implémenter cette opération.

Le schéma d’interaction est le suivant : L’utilisateur choisit un objet dans la boîte d’outil flottante (appelée « Widget menu » dans les captures d’écran), il le dépose sur le layout de Kiwi là où il le souhaite. Pour cet objet, les actions possibles sont :

- Déplacer l’objet : en utilisant le glisser/déposer à l’intérieur de la zone de travail délimitée ;

- Supprimer l’objet : en utilisant le glisser/déposer, la cible du déposer se trouvant être l’icône de la poubelle ;

- Personnaliser l’objet : en cliquant simplement sur l’objet, un cadre apparaît et l’utilisateur peut spécifier certaines caractéristiques (texte, couleur ou dimensions.

Les objets et leurs caractéristiques sont récupérés depuis l’environnement Daft au moyen d’une simple requête auprès du serveur.

Figure 45 : capture d’écran de l’application kiwi. L’utilisateur a sélectionné un ensemble de composants

et les a répartis dans la zone de travail. L’application construite est une application de saisie de renseignements pour l’inscription d’un nouvel utilisateur sur un site Web.

C. Modèle de données sous-jacent

En plus des objets classiques du DOM que l’application manipule pour représenter à l’écran les différents éléments de l’interface, Kiwi introduit plusieurs objets, qui sont nécessaires pour le bon déroulement de l’algorithme et de la communication avec le serveur : les objets graphiques et les objets de modèles.

i. Objets graphiques

L’objet MultiLayer permet de gérer la zone de travail et notamment la duplication des éléments qui y sont rattachés. Elle se divise en une zone de header comprenant les onglets permettant de changer la vue courante et une zone de contents, là où seront affichés les Widgets et les groupes sur lesquels l’utilisateur travaille.

L’objet DomContainer permet une simplification dans la programmation. En effet, la plupart des Widgets et des groupes que peut manipuler un utilisateur peuvent être ramenés à une simple boîte rectangulaire. Les traitements effectués lors de l’application de l’algorithme se font sur ces éléments et non sur les vrais objets eux-mêmes.

7.3 - Description de la Plate-forme Kiwi

Figure 46 : diagramme de classes des objets graphiques introduits par Kiwi.

Lors de l’opération de drag-and-drop qui voit un utilisateur sélectionner un Widget dans la boîte flottante (« Widget menu »), la séquence d’opération est la suivante :

- Création d’un clone de l’objet DOM présent sous la souris ; - Wrapping de cet objet dans un DomContainer ;

- Détachement de l’objet de l’arborescence DOM ; - Suivi du drag ;

- Attachement de l’objet au bon layer lors du drop de l’objet (méthode addContent(), de la Figure 46).

La méthode de drag&drop employée, malgré un volume conséquent en termes de ligne de code (~800 lignes de JavaScript), n’est pas particulièrement intéressante à développer : il s’agit d’une machine à états très simple, s’assurant que le bouton de la souris reste baissé lorsque la souris est déplacée. Les actions en rapport avec le modèle sont effectuées au moment de la récupération des différents évènements souris renvoyés par le gestionnaire d’évènements JavaScript (par exemple, la création d’un objet DomContainer).

ii. Objets du modèle

Comme nous l’avons précisé en introduction, il est nécessaire de garder une représentation du modèle du côté client de l’application. Il faut donc rajouter les objets nécessaires à l’application de l’algorithme notamment. De la même manière qu’au chapitre 7, on retrouvera la distinction entre les objets simples (appelés ici Widget), et les agrégations (appelés ici WidgetGroup).

MultiLayer

+ createBodies( ) : void + createHeader() : void

+ addContent( DomObject) : void

DomContainer

Figure 47 : diagramme de classes des objets JavaScripts introduits pour les besoins de l’application de

l’algorithme d’agrégation vu au chapitre 7. L’attribut meta_type permet de distinguer les Widgets des WidgetsGroups lors des calculs génériques.

Le modèle JavaScript est plus complexe que celui mis en œuvre dans le chapitre 6 : cela est principalement dû à la complexification des interactions avec l’utilisateur. Celui-ci peut intervenir dynamiquement sur la structure du modèle par l’intermédiaire de ses

WidgetGrid - layout : Array - width : Integer - height : Integer + explicitRegrouping( ) : void + fusion() : void

+ aggregation( DomObject) : void + ComputeMeanDistance() :void + computeLayout() : void + ComputeThresholdDistanceRel() : void + ComputeNeighbours() : void + AggregatesByDistance() : void + AggregatesByType() : void + AggregatesBySimilarity() : void Widget - name : String - meta_type: String - type : String - x_pos : Integer - y-pos : Integer - width : Integer - height : Integer -neighbours: Array WidgetGroup - childs: Array - meta_type: String - criterion: String -distance_matrix : Array -neighbours : Array -HTML_Object : DomObject -annotation_box : DomObject + wgExists( ) : void + getWGcontainer() : void + addWidget() : void + removeWidget() : void + ComputeMeanDistance() :void + computeLayout() : void + ComputeThresholdDistanceRel() : void + ComputeNeighbours() : void + { fonctions d’agrégations } est voisin de est voisin de est voisin de

7.3 - Description de la Plate-forme Kiwi

actions de constructions. La gestion de ces actions et la nécessité de garder un ensemble cohérent entre les différents objets entraînent une certaine inflation du code source (~3000 lignes de JavaScript pour Kiwi contre ~1000 lignes pour DOM Filter).

- La classe WidgetGroup représente un agrégat. Cette classe contient une liste d’éléments qui peuvent être d’autres WidgetGroup ou bien des Widgets. Elle est dotée de l’ensemble des méthodes perceptuelles qui permettent d’appliquer l’algorithme de regroupement à son niveau (calcul des voisins, de proximité, etc.). Les WidgetGroup peuvent être assimilés à des éléments concrets (des Widgets de type container), dans ce cas, la référence à l’objet DomContainer en question est renseignée.

- La classe Widget représente un élément de l’interface graphique tel que nous l’avons défini dès le chapitre 7. La liste des Widgets disponibles est obtenue à partir de la famille de composants Daft-Swing. Pour ces éléments, la modélisation JavaScript conserve, outre ses éléments graphiques, la liste de ses voisins quand ils sont calculés et les informations de type héritées de la modélisation Daft-Swing. - La classe WidgetGrid est le pendant abstrait de la zone de construction de

l’application. Elle représente le modèle complet de l’application. Il n’existe qu’une instance de la classe WidgetGrid dans l’application pour une session donnée, elle fait office de méta-classe. La liste des méthodes données dans le diagramme des classes représente l’ensemble des méthodes utilisées pour paramétrer et lancer l’algorithme d’agrégation.

iii. Utilitaires annexes

Afin de mettre en œuvre l’algorithme et les interactions, il a été nécessaire de développer une série de méthodes d’appoint permettant d’extraire de manière précise les différentes informations de couleur, de positionnement, de taille, etc. En effet, l’une des spécificités de la représentation DOM est la manière de positionner les éléments les uns par rapport aux autres : le positionnement peut être absolu (coordonnées x ou y dans la fenêtre) ou relatif (coordonnées x ou y à partir de la position du nœud parent).

D. Func View

Une application ne se résume pas à son interface graphique même si celle-ci est une partie importante. L’application finale inclut un ensemble de fonctionnalités qu’il faut réussir à définir.

A cette étape de l’implémentation, nous nous retrouvons face à une difficulté particulière : nous nous trouvons à la limite des compétences que l’on peut prêter à un futur utilisateur. Malgré tout, il est tout à fait possible que des utilisateurs puissent avoir la volonté de pousser la définition d’une application jusqu’au bout.

Pour cette raison, nous avons décidé de pousser la logique de la métaphore visuelle le plus loin possible. La vision que nous proposons est héritée du choix de modélisation fait lors la définition de Swing. En effet, dans l’ontologie de composants Daft-Swing, les fonctions sont représentées comme des agrégats de composants fonctionnels plus petits : les actions. La définition d’une fonction passe par la mise en relation de différents objets, tels que la Figure 48 le représente.

Figure 48 : Définition d’une fonction d’après Daft-Swing

C’est ce schéma qui va être implémenté sous forme graphique dans Kiwi : l’utilisateur sélectionne un composant « source », ce qui fait apparaître les modalités rattachées (telles qu’elles sont définies dans l’ontologie de composants). Enfin, il sélectionne un composant « cible », ce qui aura pour effet de faire apparaître la liste des effets pouvant s’appliquer à la cible. Ce processus est décrit dans la Figure 50.

Figure 49 : mécanisme d’annotation d’un agrégat dans Kiwi.

Target Source

Modality

7.3 - Description de la Plate-forme Kiwi

Figure 50 : définition d’une fonction à l’aide de Kiwi. Cette définition se fait en trois étapes (chiffres

rouges dans la capture d’écran) : 1) l’utilisateur sélectionne un Widget qui l’intéresse – la source de l’action – et l’ensemble des actions possibles apparaît (modalités de l’action – ce sont les rectangles intitulés DRAG, MOUSE OUT, etc) ; 2) l’utilisateur sélectionne la modalité qui l’intéresse et déplace le rectangle correspondant sur l’objet ou le groupe qui l’intéresse ; 3) lorsque l’utilisateur dépose l’objet sur la zone d’intérêt – la cible – une liste de choix lui propose la liste des opérations permises.