RESUME
La création d’interfaces à manipulation directe suppose celle de représentations interactives, personnalisées et riches des objets conceptuels de l’application. De nombreux prototypes de recherche permettent la description d’une interface à manipulation directe dans un éditeur graphique spécialisé. L’approche fondamentale de ces systèmes consiste à associer des contraintes à des objets graphiques, ces contraintes définissant la sémantique de l’application. L’inconvénient, assez largement reconnu, de cette méthode est qu’elle n’offre pas de mécanismes efficaces de modularisation, ni de séparation claire entre la partie sémantique et la partie représentation des objets. Les « Business Graphic Objects » de ILOG Views fournissent une méthode de définition interactive d’objets graphiques interactifs, intégrables à une application définie dans un langage tel que C++ ou Java. Au lieu de proposer un modèle de résolution de contraintes généraliste permettant à priori le développement de toute l’application, nous nous sommes efforcés de faciliter le développement de représentations d’objets sémantiques suivant un schéma de construction éprouvé tel que MVC. Les rôles respectifs de la partie interactive et de la partie fonctionnelle de l’application se trouvant ainsi clairement délimités, il devient plus facile de modulariser correctement, et donc créer des applications à manipulation directe réalistes, tout en bénéficiant d’outils simplifiant le développement de la représentation interactive des objets du modèle conceptuel.
MOTS CLES : Outils de construction d’interfaces, Contraintes, Schémas de construction (Design Patterns) , MVC, PAC, Construction interactive d’interfaces.
INTRODUCTION
Les outils actuels de développement d’applications interactives, comme Microsoft Visual Studio [11] sont le plus souvent construits autour d’un langage de programmation, d’un éditeur de texte doté de capacités de gestion des sources et du programme, et de ce que l’on qualifie exagérément d’un constructeur d’interface, qui permet de composer des dialogues statiques à partir d’objets prédéfinis, tels que boutons, menus, champs de texte… Ces environnements ont des limites reconnues pour la construction interactive d’interfaces à manipulation directe, que beaucoup de travaux de recherches ont cherché à circonvenir. Avant de présenter ces travaux, considérons un exemple : un objet souvent utilisé dans les éditeurs graphiques 2D, une « transformation », constituée des attributs translation X, translation Y, échelle X, échelle Y et rotation. Un développeur pressé utilisant des outils courants construira pour un tel objet un « inspecteur » de type formulaire, qui se présentera à peu près sous la forme suivante :
Cependant, un développeur désirant appliquer les préceptes de la manipulation directe [16] se doit de fournir une représentation de l’objet conforme à la signification des attributs, offrant une interaction incrémentale, rapide et réversible, et présentant de façon visuelle les actions disponibles sur l’objet. Pour cela, on peut vouloir créer un inspecteur constitué d’objets « poignées » et de traits présentant l’état des attributs, sous cette forme :
Les poignées horizontales (rouges) contrôlent des transformations en X, les verticales (bleues), des transformations en Y. Une poignée en forme de flèche indique une translation, une poignée carrée indique un changement d’échelle, la poignée ronde (verte) permet de contrôler la rotation. Le bouton central permet de remettre la transformation à l’identité. Enfin, l’ellipse et les traits indiquent visuellement l’état courant de la transformation. Il est bien sûr possible de discuter des mérites relatifs de cette représentation, de suggérer des améliorations permettant par exemple de visualiser ou d’introduire des valeurs exactes ou de modifier plusieurs attributs en une seule action.
Cependant, cet exemple illustre pour nous l’intéret d’une représentation graphique riche et personnalisée d’un objet sémantique de l’application, fournissant une interface conforme à sa nature. Lorsque cette représentation est définie, il convient de la relier à un objet sémantique, qui implante le comportement proprement dit de l’objet, par le biais du schéma de construction (design pattern) médiateur. Bien sûr, ce schéma se généralise pour la construction de l’interface entière, en représentant sur le même principe chaque objet et les relations entre ces objets.
Les «Business Graphic Objects » (BGO) de ILOG Views [7] ont pour objectif de permettre de créer interactivement de telles représentations d’objets sémantiques, et d’insérer ces présentations dans une application complexe, définie dans un environnement de développement courant.
Méthodes actuelles de construction de reprEsentations
Avec les outils utilisés couramment (avant l’introduction des BGO), la meilleure méthode pour construire de telles représentations consiste à définir dans un programme des objets graphiques spécialisés, à les composer, à leur associer un objet interacteur interprétant les actions de l’utilisateur, puis à relier cet objet à sa sémantique, par le biais du schéma ’Observeur/Observable‘. Avec une bibliothèque telle qu’InterViews [3,17], qui offre des abstractions facilitant la modularisation et la réutilisation par composition, cette tâche est assez aisée pour un développeur expérimenté, une fois que la représentation est bien conçue et spécifiée.
Cependant, il est apparu très tôt que :
· Il semblait plus immédiat et simple de dessiner directement ces représentations plutôt que de les décrire par programme.
· La mise au point d’une représentation adéquate se fait par itérations, nécéssitant une boucle serrée de modifications/évaluations, peu commode lorsqu’il est nécessaire de modifier son programme, de le recompiler et le relancer pour tester l’effet des modifications.
· La personne compétente pour définir une représentation est plutôt un spécialiste du domaine de l’application ou de l’expression graphique qu’un programmeur. Elle n’a donc pas forcément les compétences requises pour définir par programme une représentation riche, donc complexe.
Ces constatations ne sont pas nouvelles. De nombreux prototypes de recherche ont proposé des méthodes de construction interactive d’interfaces à manipulation directe. Trillium [6] est sans doute le précurseur dans ce domaine, tandis que ThingLab [12] a introduit l’utilisation de contraintes pour spécifier la dynamique graphique des objets. Garnet [13], puis Amulet [14] sont des environnements complets, basés sur une boite à outils, et permettant d’intégrer le comportement graphique des objets définis par des contraintes à une application réelle. En simplifiant, ces outils permettent à l’utilisateur de construire un dessin avec un éditeur classique de type ‘Draw’. Les objets sont tous nommés, ainsi que chacun de leurs attributs. Un éditeur permet de construire des contraintes spécifiant des relations entre attributs et entre objets qui doivent être maintenues par le système. Le modèle de résolution peut être Turing complet ou non, de nombreux algorithmes de propagation ont été proposés, et il est en général possible de définir des comportements complexes par des contraintes simples. Dans l’exemple présenté ci-dessus, on établira par exemple une relation entre la position du trait vertical rouge et la valeur de l’attribut translation X de la transformation. Une trentaine de contraintes simples suffisent à implanter notre exemple. Les BGOs ne procèdent pas différemment sur ce point.
Par la suite, la recherche dans ce domaine s’est orientée vers l’inférence de comportements à partir des actions de l’utilisateur, créant ainsi le domaine de la programmation par démonstration [5,8,9]. Cependant, on ne trouve (trouvait, avant les BGO) pas, dans la panoplie des environnements de développement disponibles commercialement et courants d’utilisation, d’outils issus de ces recherches.
Le premier obstacle, largement reconnu, tient aux difficultés de modularisation des systèmes de contraintes utilisés dans la cadre du développement d’interfaces. Dès lors qu’un système dépasse la centaine de contraintes, il semble difficile, voire impossible de maîtriser les effets de bords de la propagation. Ensuite, la frontière entre la définition de la sémantique propre de l’application et le comportement purement graphique et interactif des objets de représentation reste floue dans les systèmes proposés. Contrairement aux boites à outils, l’utilisateur ne peut se reposer sur un schéma classique tels que MVC [15] ou PAC [4] pour modulariser son application et séparer l’interface de l’application.
Mais à notre avis, la grande difficulté qui limite la vulgarisation de ces systèmes est que les langages de programmation sont éprouvés et semblent adéquats pour l’expression de l’architecture logique de l’application. Il nous semble acquis que l’expression de calculs et de structures de données se fait de façon plus naturelle par le biais d’un langage (textuel), par lequel nous sommes plus habitués à exprimer et manipuler des représentations symboliques. Or l’architecture globale, nécessairement modularisée dans le cadre d’une application réaliste, constitue le cœur et la motivation première d’un développement, et ne peut donc être sacrifiée à la construction de l’interface, combien même cette dernière en fût-elle grandement simplifiée.
Pour circonvenir ces obstacles, il nous a paru utile d’isoler le mécanisme de construction de représentations de l’expression de la logique de l’application. La séparation entre les deux modes de définition de l’application se trouve assez clairement délimitée en proposant au développeur le respect d’un schéma de modularisation classique (design pattern), tel que MVC ou PAC. Dans ce schéma, la partie représentation (contrôle et vue pour MVC) est définie dans l’éditeur interactif, tandis que la partie modèle est définie classiquement dans le langage.
Ces concepts ont permis le développement et la commercialisation des BGO, intégrés à la boite à outils ILOG Views en Java et en C++. Nous présentons maintenant l’architecture logicielle, puis l’éditeur de représentations interactives avant de présenter les utilisations actuelles et les perspective d’évolution du modèle.
PrerEquis DE la boite a outils
La mise en œuvre des BGO, comme celle des autres systèmes utilisant des contraintes et un éditeur de représentations, repose sur un certain nombre de modules logiciels. Nous présentons tout d’abord les prérequis classiques, puis les modules destinés aux BGO proprement dits.
Langage, boite à outils Views
Comme pour toute création d’interface à manipulation directe, il est nécessaire de disposer d’une boite à outils dans un langage évolué. En C++ (Views) comme en Java (JViews), Views propose une bibliothèque d’objets graphiques réutilisables, dérivables et composables. Ces objets sont placés dans des conteneurs (abstraction des fenêtres du système). Un objet graphique sait se redessiner lorsqu’il est modifié. Il est possible de lui associer un comportement (objet interacteur) et une sémantique (propriétés et callbacks). Sur ce plan, les services fournis sont similaires à ceux de nombreuses boites à outils [2].
Introspection
Afin de pouvoir créer des objets, les nommer et changer leurs attributs depuis un éditeur, c’est à dire en dehors du langage, il est nécessaire que les objets de la boite à outils soient équipés d’un mécanisme d’introspection: il doit être possible de créer et modifier les objets d’interaction en dehors du contexte du langage de programmation, voire dans un autre processus. Pour cela, les objets graphiques de base héritent en C++ d’une classe « ValueInterface », décrivant la classe, les attributs et méthodes d’un objet, d’une façon similaire aux mécanismes de liaison CORBA et COM [10]. En Java, ils utilisent le mécanisme des JavaBeans [18]. Il est possible de retrouver et modifier la liste des attributs d’un objet, de consulter et modifier leurs valeurs depuis un processus externe tel que l’éditeur de dessin. Bien que simple à décrire dans son objectif, ce module constitue une véritable surcouche du langage. Il alourdit quelque peu la programmation et l’extension de la boite à outils, puisqu’il requiert la fourniture d’une description supplémentaire des attributs de chaque nouvelle classe créée. Des mécanismes de ce type sont courants dans les boites à outils comme Garnet ou Amulet.
Ajout dynamique d’attributs
Afin de pouvoir ajouter une liaison sémantique à un objet, et surtout un comportement, les objets graphiques peuvent être complétés de nouvelles propriétés, ajoutées dynamiquement.
Ces propriétés peuvent être de trois types :
1. Des attributs additionnels, correspondant aux attributs de l’objet sémantique représenté. Si par exemple on souhaite représenter un objet « thermomètre » par un ascenseur (slider) - objet prédéfini de la boite à outils - on ajoutera 4 variables, nommées « température », « seuil », « min » et « max ». Ces attributs définissent l’interface applicative de l’objet considéré, et sont les seuls attributs qu’aura besoin de voir l’application pour un objet donné. Ces attributs peuvent être publics ou privés, persistants, et peuvent notifier l’application de leurs changements de valeur ou non.
2. Des contraintes décrivant une relation à satisfaire entre un ou plusieurs attributs (natifs ou additionnels). Une telle contrainte peut par exemple se déclencher lorsque l’attribut « température » décrit précédemment dépasse l’attribut « seuil ». Elle peut avoir pour effet de faire passer la couleur de l’ascenseur (attribut natif) en rouge pour alerter l’utilisateur. L’ensemble des objets et contraintes graphiques associées définissent la présentation de l’objet sémantique. La propagation des changements d’attributs permet de définir des comportements complexes par composition de contraintes simples.
3. Des comportements interactifs: des interacteurs, ou comportements standards (clic sur l’objet, glisser déplacer de l’objet…) peuvent être associés à l’objet et à des contraintes interactives. Ces contraintes sont déclenchées par des événements utilisateurs et ont pour effet de modifier des attributs de l’interface applicative en fonction de la nature des événements captés. Par transitivité, les contraintes de présentation seront déclenchées par la modification des attributs, et par conséquent la représentation de l’objet est maintenue cohérente.
Par exemple, on représentera le thermomètre sous la forme d’un rectangle plein et d’un rectangle vide groupés, nommés respectivement « Remplissage » et « Contenant » :
On ajoute quatre attributs additionels de type flottant: min, max, température et seuil, en précisant que ces attributs sont persistents, publics et notificateurs. Puis on ajoute quelques contraintes spécifiant les relations entre valeur des attributs et apparence :
Remplissage.height=
température*Contenant.height
/(max-min)
Remplissage.color=
température >
seuil?« Red »:« Blue »
Enfin, on peut ajouter un comportement interactif :
On
mouse.drag over Contenant:
température=
mouse.position.y-Remplissage.bottom
Ce comportement indique que lorsque l’utilisateur clique et déplace la souris
sur le rectangle « Contenant »,
« température » est ajustée en fonction de la position actuelle de la souris. La véritable
expression est un peu plus complexe, mais le principe reste le même.
L’originalité des BGO sur ce point est que chaque objet est un système de contraintes à part entière, isolé des autres contraintes, et accessible seulement par le biais des attributs publics, lesquels ne sont reliés a priori qu’à la sémantique propre de l’application définie dans le langage de programmation. Ce principe est très limitateur, car il empéche l’établissement de relations entre des objets distants pour spécifier par exemple des positions relatives entre objets représentés ou d’autres attributs globaux. Il nous paraît cependant critique pour l’utilisabilité globale du système : il suffit en général de peu de contraintes pour décrire la représentation d’un objet individuel. En revanche, avec un système de contraintes non–encapsulées, il est tentant de construire tout ou partie de la partie logique (contrôle au sens de PAC) de l’application dans le système de contraintes. Celui-ci ne fournissant pas de mécanisme simple de modularisation, l’utilisateur se trouve incapable de maîtriser la taille croissante du système.
Par ailleurs, la séparation est définie de façon assez stricte entre les contraintes de contrôle, allant des événements utilisateur aux attributs logiques, et les contraintes de présentation, allant des attributs logiques aux attributs de présentation (forme et aspect des objets graphiques). Ce schéma est exactement celui de MVC. Il guide le concepteur d’objets interactifs en créant implicitement une modularisation claire de la représentation de l’objet.
LIAISON REPRésentation-application
Comme nous l’avons indiqué précédemment, les mécanismes de définition de contraintes des BGO sont conçus pour servir exclusivement à la définition de la relation entre les attributs d’un objet et sa représentation, à l’exclusion de toute logique interne à l’application. Cela impose que chaque objet applicatif que l’on souhaite pouvoir présenter soit relié à une instance de BGO. Il existe deux façons possibles de procéder :
· Dans une situation idéale, l’objet applicatif hérite de la classe « ValueInterface » (ou est un JavaBean en Java), lui donnant des capacités d’introspection et de notification de ses changements de valeurs. Dans ce cas, il suffit de créer une instance appropriée de BGO pour chaque objet applicatif. Une liaison lexicale simple entre les attributs du modèle et ceux du BGO est établie et permet au moteur de la boite à outils de gérer de façon transparente la cohérence entre l’état interne de l’objet, sa représentation (dès lors qu’elle a été instanciée) et les actions de l’utilisateur.
· Cependant, il n’est pas réaliste dans un contexte industriel de demander à un utilisateur de construire son application en se reposant sur les mécanismes fournis par la boite à outils graphique. C’est pourquoi on propose à l’utilisateur la création d’objets médiateurs chargés de notifier l’objet applicatif d’une action de l’utilisateur, et observant un objet applicatif pour refléter les changements de ses attributs dans l’interface. Par exemple, dans le cas de l’exemple « thermomètre », relié à un logiciel de contrôle d’usine, cet objet aura l’interface suivante:
class ThermometerMediator :
Mediator {
ThermometerMediator(Thermometer*t,
Scene*
s) {
instanciation du BGO représentation de
t dans la scène s
}
void updateObject(Attributes* a) {
l’utilisateur a changé une valeur et
l’objet thermomètre
doit en être notifié
}
void updateBGO() {
cette fonction doit être appelée de
façon interne à
l’application pour notifier
l’interface de changements de
l’état interne de l’objet.
}
} ;
Lorsque cette classe a été définie pour une classe particulière d’objets applicatifs, l’interface se trouve totalement découplée de l’objet fonctionnel : Il devient possible à un concepteur graphique de travailler sur la représentation propre de l’objet, dans l’éditeur de dessin et de représentations, tandis qu’un développeur pourra faire évoluer la logique interne de l’objet et sa liaison avec d’autres objets de l’application. Seuls des changements de l’interface publique de l’objet (ajout ou suppression d’attributs pour lesquels on souhaite fournir une représentation à l’utilisateur) nécéssitent une modification de la classe médiatrice et un accord entre le concepteur de l’application et celui de la représentation des objets.
ARCHITECTURE DES BGO
Le schéma suivant récapitule les consistuants d’un BGO implantant
l’interface d’un objet applicatif :
L’utilisateur part a priori d’une structure d’objets applicatifs. Des médiateurs sont définis pour chaque classe devant être munie d’une représentation. Un mécanisme d’instanciation des représentations, se présentant sous la forme d’une usine (factory), associe à des classes de l’application des noms de BGOs définis et les instancie dans une scène donnée. La partie BGO est entièrement définie dans l’éditeur graphique spécialisé Studio que nous présenterons ci-après. La phase de définition de la représentation et de l’interaction est donc entièrement définie dans l’éditeur interactif qui enregistre les objets modèles dans des fichiers lus à l’initialisation de l’application. Il est ainsi aisé de séparer totalement conception de la logique de l’application et conception des représentations et de les faire évoluer en parallèle.
Bibliothèques de prototypes
Toute application se composant d’instances de classes dérivables et composables, il convient de fournir un mécanisme similaire de réutilisation et de spécialisation des classes de représentation d’objets.
Tout BGO peut être conservé dans une bibliothèque regroupant des BGOs de caractère commun. Ainsi, une bibliothèque de schémas de composants électroniques (résistances, transistors, capacités…) est fournie dans les exemples d’utilisation.
Les BGOs sont eux-mêmes clonables. Ainsi, on peut associer un prototype de BGO à une classe de l’application, et le cloner pour représenter chaque instance de la classe. Pour permettre la spécialisation, il est possible de déléguer certains comportements à un autre BGO qui peut ainsi servir de prototype pour une portion de la représentation. Il est également possible de composer des BGOs pour fournir des représentations d’objets composites.
Construction interactive de BGO
Le modèle des contraintes utilisé dans les BGO est très sommaire (propagation unidirectionelle), mais s’avère suffisant étant donné la structuration forte suggérée par l’interface permettant de construire un BGO. En effet, le moteur de contraintes est généraliste et a priori toute modification d’attributs peut déclencher une propagation vers d’autres attributs. C’est donc par l’interface présentée pour la construction que l’on permet à l’utilisateur de structurer ses BGOs par un modèle similaire au modèle MVC, et donc éviter les risques de perte de maîtrise de la structure de l’application.
Editeur de représentations
L’éditeur de BGO ressemble en bien des points à un éditeur de dessins ou de dialogues classique. Il propose une palette d’objets prédéfinis : rectangles, lignes, texte… ainsi que des composants plus complexes : boutons, menus, barres de défilement, matrices…
Cet éditeur permet de construire des conteneurs en instanciant ces objets et de les enregistrer pour les lire dans une application. Les objets peuvent être composés, il est possible de leur associer des comportements interactifs en leur associant des interacteurs prédéfinis. La sémantique de ces comportements peut être définie soit dans un langage de scripts (JavaScript), soit en spécifiant le nom de callbacks C++ qui seront définies dans le source de l’application. Il est possible d’intégrer ses propres classes d’objets, et parmi ces classes figurent les bibliothèques de prototypes prédéfinis ou créés par l'utilisateur. Un BGO se manipule de ce point de vue comme un objet graphique ordinaire. Pour tout objet, on peut demander à faire apparaître l’éditeur de comportements qui permet d’en faire un BGO, c’est à dire lui associer une sémantique et un comportement graphique et interactif. La plupart du temps, cet objet est un composite édité dans sa propre fenêtre.
Editeur de comportements
L’éditeur de comportements est composé de quatre volets, munis chacun d’une aide en ligne contextuelle indiquant la marche à suivre à chaque étape:
1. Interface. Le premier panneau permet de définir une liste d’attributs représentant les attributs sémantiques de l’objet, avec leurs types et valeurs initiales. Lorsque ces attributs sont précisés, l’éditeur propose à l’utilisateur de dessiner la représentation de son objet. A tout moment, cette interface peut être modifiée ou enrichie, car l’évaluation des contraintes et l’interface avec l’application reposent sur une liaison purement lexicale.
2.
Contrôle des objets graphiques. La page
suivante permet de renommer les objets graphiques constituant la représentation, de
les rendre visibles ou invisibles, de controller leur ordre d’affichage…
3.
Comportement graphique. L’étape suivante
consiste à définir comment les modifications des attributs de l’interface
influent sur la représentation. Cette page présente la liste des attributs de
l’interface et une liste de comportements prédéfinis (affectation, test,
sélection, transformation…) dans la barre de menus. En sélectionnant un
attribut, puis un des comportements, on ajoute une clause ‘do’ à l’attribut. Le
comportement ajouté sera évalué à chaque fois que la valeur sera modifiée. Il
est possible d’associer autant de comportements que nécéssaire pour chaque
attribut. Il est également possible de créer des attributs intermédiaires,
privés, qui serviront à préciser l’ordre d’évaluation ou à factoriser des
déclenchements de comportements. En règle générale, 2 ou 3 comportements
graphiques par attribut sont suffisants pour représenter graphiquement la
valeur d’un attribut.
4.
Comportement interactif
La dernière page se présente comme la troisième : Une liste d’attributs
« Actions » pourvus chacun de clauses ‘do’. Cette fois, l’utilisateur
choisit le type d’événement susceptible de déclencher un comportement :
callback déclenchée par un interacteur ou événement clavier ou souris. Un
attribut ‘Action’ est créé pour chaque événement déclencheur, et l’utilisateur
peut ajouter autant de ‘briques de comportement’ que souhaité pour chaque
événement, dans la clause ‘do’. Pour guider l’utilisateur, un choix est proposé
parmi la liste des attributs définis dans la page ‘interface’. Ainsi,
l’utilisateur est guidé pour favoriser une modularisation de type MVC dans la
définition de son BGO. En général, pour chaque modification d’attribut, il faut
définir trois actions (enfoncer le bouton, déplacer, relacher).
A titre d’exemple, l’éditeur de transformations, particulièrement
complexe car il requiert des variables intermédiaires pour préciser l’ordre
d’évaluation des rotations et changements d’échelle, requiert la définition de
cinq attributs d’interface, une trentaine de
comportements graphiques et une quarantaine de comportements
interactifs. Le tout est construit en une vingtaine de minutes pour un
utilisateur à l’aise avec la trigonométrie requise pour ce cas.
Enfin, la totalité de la représentation et son comportement étant définis dans l’éditeur, ceux-ci peuvent être testés interactivement à tous les stades de leur évolution, sans requérir de liaison avec un noyau fonctionel.
utilisation actuelle
La demande des BGOs provient en grande partie de clients traditionnels de Views. Ces clients construisent pour la plupart des synoptiques : tableaux de contrôle d’usines, centrales nucléaires, contrôle aérien, réseaux de télécommunications, réseaux autoroutiers… Les opérateurs des applications développées travaillent dans des situations demandant une grande vigilance et un suivi très précis de l’évolution des objets, ce qui justifie un développement important et une représentation particulièrement soignée des objets applicatifs.
Nous suivons les travaux d’une petite dizaine de clients particulièrement impliqués dans l’expression des besoins des BGOs. Un fait notable que nous avons constaté est que ces clients, qui disposent souvent de moyens importants, opèrent progressivement une transition dans leurs méthodes. Ainsi, l’un de nos clients, en charge du développement de simulateurs de centrales nucléaires, a commencé son projet avec environ 10 développeurs C++ et 3 graphistes en charge de fournir la représentation des panneaux et instruments de contrôle. Un an plus tard, la proportion s’est inversée, avec seulement 3 développeurs et une dizaine de graphistes.
Il ne nous est pas possible de présenter les synoptiques créés par les clients pour des raisons de confidentialité. Les applications tests que nous avons réalisées sont souvent d’un graphisme très sommaire par rapport à ces applications, car nous nous focalisons sur la fourniture de mécanismes et non de composants directement réutilisables.
Dans les quelques exemples que nous fournissont figurent un éditeur de
schémas électroniques, un constructeur de synoptiques d’usine, un simulateur de
contrôle aérien minimaliste, un simulateur de vol sommaire, implanté sans
utiliser une ligne de code C++ ou Java. En effet, le moteur de résolution de
contraintes est Turing-complet, et permet à priori de développer une
application entièrement autonome bien que ce ne soit pas son objectif.
PERSPECTIVES
Bien qu’ayant trouvé un domaine réel d’utilisation, nous considérons que les BGOs pourraient bénéficier à un cadre plus large d’applications : toute application dans laquelle l’utilisateur doit manipuler des objets applicatifs complexes et bénéficier d’une représentation conforme à l’objet manipulé. Par exemple, le premier auteur a travaillé en 1995-97 sur un logiciel de dessin [1] permettant (entre autres) de créer des pinceaux de caractéristiques variées en modifiant une trentaine de paramètres : largeur, transparence, dégradé, continuité, sensibilité à la pression… Les concepteurs du logiciel ont beaucoup travaillé à l’aspect graphique d’un éditeur permettant de visualiser et maîtriser tous ces paramètres facilement. Cependant, l’éditeur du produit a toujours été largement en deça de sa conception originelle, car il est extrèmement difficile de créer et contrôler par programme tous les objets graphiques nécéssaires à l’éditeur de pinceaux. De plus les itérations sur le programme sont délicates et longues. Nous considérons que l’utilisation d’un système tel que les BGOs aurait permis de construire des éditeurs plus satisfaisants pour les utilisateurs finaux de ce logiciel.
Quelques maquettes d’éditeurs interactifs
de pinceaux
conçues et non implantés dans un
logiciel de dessin
Bien sûr, l’implantation actuelle des BGOs souffre de quelques limites : occupation mémoire importante et performances réduites par rapport à des objets graphiques compilés. Ces inconvénients ne sont pas rédhibitoires, mais doivent être améliorés dans une perspective industrielle. Pour cela, nos étudions la possibilité de compilation de BGOs par évaluation partielle des contraintes et des fonctions de dessin. Sur un plan plus conceptuel, nous étudions des mécanismes plus généraux appliquant la notion de comportements à des groupes d’objets, en incluant la création dynamique de représentations dans l’éditeur interactif. Enfin, comme nous l’avons déjà indiqué, les BGOs requièrent de construire ou d’utiliser une couche d’introspection au dessus du langage. Le mécanisme de clonage est lui–même une extension du langage. Nous en concluons que la conception d’un langage approprié à l’expression des mécanismes mis en œuvre dans les BGOs faciliterait grandement le développement d’outils similaires. Cependant, la pragmatique industrielle ne nous recommande pas cette voie de développement.
conclusion
Les BGOs sont utilisés avec satisfaction depuis maintenant deux ans pour la création d’applications de type synoptiques, pour lesquelles la création de représentations riches et personnalisées des objets de l’application est primordiale. La décision de restreindre la portée d’utilisation des contraintes à la définition seule de la représentation et l’interaction d’un objet sémantique, et la conception de l’interface de définition des BGOs pour favoriser le suivi d’un schéma de type MVC permet selon nous de circonvenir aux difficultés rencontrées pour permettre la définition interactive d’interfaces à manipulation directe. Bien qu’en grande partie issu de considérations d’ingéniérie, il nous semble établi qu’un langage textuel est plus à même de décrire la structuration et la logique d’une application réelle. En revanche, la création de représentations peut être facilitée par l’utilisation d’un éditeur graphique et l’emploi de contraintes. C’est en fournissant un mécanisme de liaison permettant une modularisation correcte de l’application que les BGOs contribuent à faciliter le développement d’interfaces et peuvent le mettre à la portée de catégories d’utilisateurs plus qualifiés dans ce domaine : graphistes et spécialistes du domaine, plutôt que programmeurs.
REMERCIEMENTS
Les BGO sont l’une des extensions de Views, qui est une boite à outils complète, multi-plateformes, multilingue, et fourni un grand nombre d’autres fonctionnalités. Les BGOs en eux-mêmes ne fourniraient pas un service appréciable sans ce support de base. Patrick Mégard, Fabien Lelaquais et les équipes Views et JViews ont très largement contribué à la conception et l’implantation réussie des BGOs. Enfin, merci à Patrick Albert de m’avoir motivé pour rédiger cet article qui était en gestation depuis trop longtemps déjà. Tous renseignements complémentaires sur Views et les BGOs peuvent être obtenus à l’adresse http://www.ilog.fr.
BIBLIOGRAPHIE
1. Alias|Wavefront, StudioPaint User’s Manual, version 4.0, 1997.
2. Baudel T. Principes et architecture des boites à outils. Notes pour le tutorial présenté à la conférence IHM98. 1998. http://www-ihm.lri .fr/~thomas/Docs/Toolkits/CourArchi/cours.html
3. Calder, Paul R. & Linton, M. Glyphs : Flyweight objects for user interfaces. In Proceedings of the ACM Siggraph Third Annual Symposium on User interface software & technologies, pp. 91-101. 1988.
4.
Coutaz, J. Interfaces Homme-Ordinateur, conception et réalisation, Dunod, pp.
161-242. 1989.
5.
Cypher, A,
Halbert, C. Kurlander, D. Lieberman, H. Maulsby, D., Myers, B. & Turransky,
eds. Watch what I do : Programming
by Demonstration, MIT Press, 1993.
6.
Henderson, A. The Trillium
User Interface Design Environment. Proceedings of SIGCHI Conference on
Computer-Human Interaction, CHI’86, ACM, pp. 221-227.
7.
ILOG, Views user’s manual. Ch. 13, Prototypes, 1993-2000.
8.
Landay, J. &
Myers, B. Interactive sketching for the
early stages of user interface design. Proceedings of the CHI’95 conference
on Human Factors in Computing System. ACM & Addison Wesley, pp. 43-50.
9.
Lieberman, H. Ed.
Programming by Example, Special
Issue, Communications of the ACM, March 2000, pp. 72-114.
10.
Microsoft Corp. Inside OLE. Microsoft Press. 2000.
11.
Microsoft Corp. Visual Studio C++ development environment. Microsoft
Press. 1985-2000.
12.
Moloney, J., Borning,
A. & Freeman-Benson, B. Constraint technology for user-interface
construction in ThingLab. Conference Proceedings on Object-Oriented
programming systems, languages and applications, ACM, 1989, pp. 381-388
13.
Myers, B. Guise,
D. Dannenberg, R. Vander Zanden, B. Kosbie, S. Pervin, E. Mickish, A. &
Marchal P. Garnet : Comprehensive
support for graphical, highly interactive user interfaces. IEEE Computer,
vol. 23, no 11, 1990.
14.
Myers, B. et al. The
Amulet environment : New models for effective user interface developmnent, IEEE Transactions on Software Engineering,
vol. 23, no 6. 1997
15.
Schmucker, K, J. Object Oriented Programming for the
Macintosh, Addison-Wesley, 1987. pp. 271-300.
16.
Shneiderman, B. Direct Manipulation : a step beyond
programming languages. IEEE Computer, Aug. 1983, pp. 57-69.
17.
Stanford
University. InterViews Reference Manual,
Version 3.0, 1991.
18. Sun Corp. JavaBeans: A Component Architecture for Java. 1999. Téléchargeable à http://java.sun.com