Les Principaux Services d'une Boite à Outils

Thomas Baudel, Ilog, contribution a l'atelier ALF.
 
Introduction

Il existe un vaste choix d'outils de construction des interfaces, pour des raisons matérielles et historiques (différents constructeurs, progrès technologique) ou pour répondre à des besoins différents: interaction graphique ou interfaces pour l'informatique de gestion, prototypage ou application à contrainte de performance forte, progiciel ou développement à façon. Cependant, de nombreux concepts se retrouvent entre ces outils, hélas rarement explicités. Nous présenterons donc les bases logicielles communes aux outils actuels, leurs motivations et d'entamer une taxonomie de ces outils.

Tout d'abord, on distingue 3 couches logicielles dans les outils de construction d'interfaces:

Cette contribution se propose de présenter les principaux services constituant une boite à outils, en vue d'établir des sous-taxonomies des boites à outils et stratégies d'implantation existantes pour chaque sous-partie. Nous commencons par un rappel sur la structure des bibliothèques logicielles de base, qui peuvent être considérés comme des modules de la boite à outils, et a se titre mériter également une étude approfondie. Nous présentons ensuite, de facon succinte, les deux grands pivots d'une boite a outils: la structure de données reposant sur la notion d'objet d'interaction et les mécanismes de communications entre ces objets. Nous énumérons ensuite l'ensemble des services qui nous paraissent saillants dans les boites a outils, avant de présenter le role principal de la boite a outils: la définition de composants prets a l'emploi.
 
 
Bibliothèques logicielles de base

L'objectif d'une boite à outils est de fournir un cadre de programmation adéquat pour implanter certaines portions de l'interface utilisateur d'une application. Par la suite, nous considérerons essentiellement des applications à caractère graphique telles qu'on les trouve actuellement sur les stations de travail et ordinateurs personnels. Lorsque cela nécessaire, nous évoquerons les possibilités/restrictions qui se posent pour d'autres environnements matériels. Il convient cependant de préciser ce qu'on entends par cadre de programmation"

Un cadre de programmation est une bibliothèque de composants  chargés de maintenir des structures de données et réaliser des opérations communes à la réalisation d'applications interactives à caractère graphique. Entre autres, il s'agit de gérer les entrées de l'utilisateur, le dessin, les contraintes de positionnement, les ressources (en définissant ce qu'est une ressource...), gérer l'insertion de l'application dans un environnement et établir un lien entre les objets d'interaction et la sémantique de l'application.  Des services supplémentaires peuvent être inclus, et le sont souvent: gestion de l'annuler/refaire (lien fort avec la sémantique), gestion de l'aide en ligne, copier/coller, voire au dela de l'interaction, avec un support pour les entrées/sorties (persistance ou SGBD, réseau...).

Une toolkit repose sur un langage, un OS et un environnement d'utilisation (GUI du système hôte). Ce chapitre présente sous forme de note les principales caractéristiques des bibliothèques de bas niveau sur lesquelles elles reposent.

Modèles graphiques

Modèle d'affichage:  direct (le réaffichage est explicite), indirect (une liste d'objets graphique est maintenue par l'application,
Modéle de dessin: sans état (tous les paramètres du dessin sont spécifiés explicitement), avec état:

Double buffer, mécanismes de clipping, notion de port graphique, systèmes de coordonnées, matrices de transformations, modèles de couleurs, polices de caractères, gestions des pixmaps.

Exemples:

Modèles d'entrée

Entrée synchrone: exemple: printf/scanf, GKS.
Entrée asynchrone: interruptions, mécanismes d'événements.

Exemples:

Systèmes de fenêtrage et intégration dans l'environnement

Toute application interactive s'insère dans un système hôte. L'utilisateur étant naturellement multitâche, il importe que son outil supporte les besoins de son activité en lui permettant d'utiliser plusieurs applications et de faire communiquer ses applications entre elles.

Exemples:

Autres couches logicielles de base

Bibliothèque audio
Bibliothèque vidéo

Ces deux médias ont pour particularité de traiter des informations évoluant dans le temps, remettant en cause la notion d'objet d'interaction figé dans le temps (Visible ou non).

Note sur les toolkits multi-plateformes

Une boite à outils multi-plateformes présente une implantation abstraite des bibliothèques de base et réalise un adaptateur sur ces primitives pour chaque plate-forme considérée.
 
Boites à outils et structuration des objets interactifs

Notion d'objet interactif

Au centre de toute boite à outils se trouve la notion d'agent (objet réactif, interacteur, glyph, widget...). Une application se définit comme un ensemble de tels objets fournissant les fonctions suivantes: Ces objets interactifs représentent (pour l'interface de donnée) le modèle conceptuel implicite de l'application: en gros, ils suivent de près le modèle de données de l'application, mais peuvent être adaptés pour les représenter de facon plus pertinente au concept. Par exemple, un objet interactif présentant une transformation 2D possédera les attributs 'Translation, Rotation, Echelle' plutot que 6 paramêtres d'une matrice.

Ces objets sont composables, hiérarchisables et spécialisables, avec plus ou moins de facilité suivant les boites à outils. La structure des objets et le langage influent fortement sur les possiblités d'extension et de modularisation offertes par la boite a outils: Organisation en arbre, en DAG ou à plat (permettant d'utiliser efficacement un quadtree), layering (physique et/ou conceptuel...).

Mécanisme de communication entre les objets graphiques, avec le noyau applicatif et avec l'utilisateur

Ces objets interactifs ne peuvent se concevoir de facon isolée: ils doivent représenter une hiérarchie de concepts signifiant l'application. Pour cela, ils doit être possible d'établir des liens fonction de la sémantique de ces objets. Un ou plusieurs mécanismes représentant le niveau de couplage entre ces objets et la dynamicité de ce couplage peuvent être utilisés dans une bvoite a outils:

cf. CR de l'atelier IHM99: échelle des mécanismes de communication

Communication synchrone ou asynchrone....
 
 
Services fournis par les boites à outils
Composants prédéfinis des boites à outils et leur extension

Composants prédéfinis

Mécanismes d'extension

Paramétrage: (ex: ressources Xt/Motif)
Redéfinitions: (ex: Mac toolbox)
Dérivation (ex: Views, ou autres)
Composition (ex: InterViews)
Notion de 'direction de dérivation'
Délégation
 
 
Conclusion

Exemples de toolkits: InterViews/Fresco, IlogViews, X/Motif, Win32/MFC, AWT, tk/tcl, MacOS toolbox, gnutk, DPS...

La taxonomie que nous avons présentée ne se prêtant ni complète ni formelle. Il nous parait utile de disposer d'une meilleure description des boites à outils, de leurs caractéristiques et leurs propriétés, ainsi que des solutions adaptées et ou adoptables dans chaque sous-domaine. C'est ce type de sujet que nous souhaitons orienter les travaux de l'atelier: Établissement d'une taxonomie plus précise des boites à outils, de leurs mécanismes fondamentaux et des services qu'elles proposent.
 
Bibliographie