Une boite à outils d'éléments du dialogue (Guillaume Texier) ------------------------------------------------------------ La conception d'une Application Graphique Interactive (AGI) et en particulier d'un système de CAO, nécessite de prendre en compte trois aspects très différents: ce que fait l'application, la présentation qu'elle offre sur l'écran et enfin le dialogue qu'elle supporte avec un utilisateur. Afin de structurer le travail des concepteurs de telles applications, des modèles d'architectures logicielles ont été proposés. Ils préconisent habituellement de séparer la partie noyau fonctionnel (actions constructives et de représentation des objets de l'application), de la partie contrôle du dialogue, et de la partie présentation de l'interface. Les concepteurs utilisent ces modèles d'architecture principalement de la manière suivante : 1) Ils créent d'abord le noyau fonctionnel. 2) Puis ils implémentent la partie présentation en utilisant une boite à outils de présentation composée de widgets. 3) Enfin ils créent le contrôleur du dialogue en liant les "callbacks" associés aux "widgets" aux actions du noyau fonctionnel. Cette méthode de conception est simple à mettre en ¦uvre pour les applications ne possédant que des tâches simple du point du vue de l'interaction, c'est à dire portant sur un unique objet. Cependant, cette méthode de conception n'est pas aisée à adapter en CAO car les tâches: - portent sur plusieurs objets à la fois (ex: créer une droite tangente à deux cercles), - sont structurées (ex: créer un cercle dont le rayon est la distance entre deux objets). Pour créer le contrôleur de dialogue de ces systèmes, l'association des callbacks et des widgets ne suffit plus. L'organisation des widgets ne reflétant pas la structure du dialogue, il faut coder dans les "callbacks" une grande partie du contrôle de l'application. La notion d'interacteur a donc été introduite afin de modéliser le contrôleur du dialogue de telles applications. Dans le modèle H4, développé au sein du laboratoire, ces interacteurs sont organisés hiérarchiquement pour permettre la structuration en tâches et sous-tâches du dialogue. Ils activent des questionnaires réalisant la communication avec le noyau fonctionnel. Ces questionnaires sont spécifiés et réalisé par le concepteur. Ils peuvent traduire des interactions multi-objets. La méthode de conception correspondant à la mise en ¦uvre de cette architecture se décompose alors en cinq étapes: 1) créer les actions du noyau fonctionnel, 2) créer le contrôleur de dialogue en créant les interacteurs et les questionnaires, 3) lier les action du noyau fonctionnel aux interacteurs en utilisant les questionnaires, 4) réaliser la couche de présentation à l'aide des widgets, 5) lier les widgets au contrôleur de dialogue via les callbacks. Afin de réduire la complexité de conception, nous avons crée une boite à outil du dialogue composée d'un ensemble de classes permettant d'instancier les interacteurs et les questionnaires. Ainsi, pour réaliser l'application le concepteur 1) crée le noyau fonctionnel, 2) définit le contrôleur de dialogue grâce à la boite à outils du dialogue 3) lie les actions aux interacteurs en utilisant les questionnaires. La présentation est générée automatiquement à partir de la description du contrôleur de dialogue. On retrouve ici le mode de conception des AGI-CT décrit au début, mais dans ce cas les widgets sont remplacés par les interacteurs et les callbacks par les questionnaires. Cette méthode présente l'intérêt, pour le programmeur, d'être du même ordre de complexité que l'usage des callbacks tout en supportant naturellement les tâches multi-objets et la structuration des tâches et sous-tâches. De plus, elle permet de définir une meilleur organisation et un contrôle plus fin de l'application.