Précédent : Pilotage de programmes Remonter :
Pilotage
de programmes Suivant : Modélisation des
connaissances
Participants : Sabine Moisan, Jean-Paul Rigault, Régis Vincent
Mots-clés : pilotage de programmes, génie logiciel Le but de cette plate-forme est de fournir un environnement commun à différents systèmes de pilotage, comportant par exemple un langage de description et des facilités de vérification de bases de connaissances, ou des interfaces graphiques. Grâce à une telle plate-forme, il est possible de tester plusieurs moteurs sur une même base de connaissances ou plusieurs applications avec le même moteur tout en gardant le même environnement de développement.
Nous avons finalisé la première beta version de la plate-forme LAMA (L ibrary A nd platforM for plA nning).
Figure 1: Chaque couche de l'architecture de
LAMA correspond à un niveau d'expertise. Le centre (en rayé) est
constitué d'une bibliothèque de composants réutilisables pour
construire des moteurs. Le niveau LAMA est celui de la
plate-forme avec le langage de description de bases de
connaissances YAKL, des outils de vérification (V&V), des
modes de développement sous Emacs et des outils optionnels comme
les interfaces graphiques ou l'apprentissage. Les moteurs de
pilotage sont basés sur LAMA et le niveau supérieur est celui des
concepteurs de bases de connaissances (Applications).
La plate-forme (voir figure 1 ) comprend une bibliothèque de composants réutilisables pour construire des moteurs de pilotage de programmes, un langage de description de base de connaissances (YAKL ), un serveur de messages (LAD ), des interfaces graphiques, des outils de vérification de base de connaissances et des mécanismes de récupérations d'erreurs.
Bibliothèque de composants. Le moteur d'un système de pilotage implante les caractéristiques d'une stratégie particulière de pilotage. Si la stratégie est figée dans le moteur, il peut être difficile de la modifier. Toute évolution de spécifications, de besoins ou de contraintes nécessite alors de reconfigurer le moteur, voire de le ré-écrire complètement. Nous proposons de pallier cet inconvénient en permettant la construction des moteurs à partir d'une bibliothèque de composants de base. Nous avons porté un effort particulier sur la phase de planification, car c'est une sous-tâche importante du pilotage de programmes. L'utilisation d'une telle approche permet de décrire une stratégie de raisonnement à un niveau abstrait, plus simplement et plus rapidement qu'avec un langage de programmation, et de la faire évoluer plus facilement. En effet, le travail de réécriture de moteurs en différents langages ou l'écriture de variantes d'un même moteur, nécessaires pour des tests ou des domaines d'applications différents, sont très fastidieux et coûteux en temps.
La bibliothèque de composants comprend, d'une part, des structures représentant les concepts intervenant en pilotage de programmes et d'autre part des instructions nécessaires à la description des stratégies de raisonnement en pilotage. C'est une bibliothèque de classes représentant les structures de données élémentaires, utilisées par des instructions (instructions de raisonnement), qui peuvent facilement être combinées pour modéliser différents mécanismes de pilotage [11]. Nous avons choisi d'implanter la bibliothèque tout d'abord en Lisp, pour ses facilités de maquettage, puis en C++ pour sa large utilisation et sa portabilité. Cette approche permet une vision unifiée de différents moteurs et fournit une base commode de comparaison entre stratégies de pilotages.
Langage de description de bases de connaissances . YAKL (Yet Another Knowledge base Language) permet de décrire le contenu d'une base de connaissances, sans préjuger du langage d'implémentation cible (Lisp ou C++). Ce langage sert à la fois de format de stockage commun à tous les moteurs de la plate-forme et de langage d'écriture ou de consultation de bases de connaissances. YAKL offre une syntaxe proche de la façon de s'exprimer de l'expert pour décrire les opérateurs, les buts, les règles de production qui constituent une base de connaissances. Des outils de vérifications lui sont connectés et le code en langage d'implémentation cible est généré automatiquement.
Un mode Emacs associé a aussi été développé afin de fournir une aide syntaxique à l'écriture de bases de connaissances. Il permet, grâce à des menus, d'écrire plus facilement les descriptions des différentes parties d'une base.
De plus, afin d'assurer un passage plus facile des anciennes bases écrite avec l'outil OCAPI vers la nouvelle plate-forme, nous avons écrit un traducteur du format interne d'OCAPI vers YAKL. Ce traducteur, appelable depuis OCAPI, ne fournit pas une traduction complète, en particulier pour les notions inconnues d'OCAPI comme les préconditions ou les effets des opérateurs.
Serveur de messages LAD. Un système de pilotage de programmes est un sytème réparti, constitué de plusieurs processus applicatifs communiquant entre eux, plus ou moins synchronisés les uns avec les autres (interface, moteur, bibliothèque de programmes, etc). Chaque processus doit garder ses caractéristiques propres tout en étant capable de communiquer avec d'autres processus ponctuellement ou de façon prolongée. En particulier les programmes préexistent souvent au système de pilotage, ils fonctionnent sur des machines ou des systèmes particuliers et ils doivent pouvoir continuer à être utilisés de manière autonome dans les mêmes conditions. De plus, un système de pilotage peut être amené à fonctionner comme un sous-système spécialisé d'un système plus général. Par exemple, un système de classification d'objets à partir d'images peut déléguer des tâches de traitement d'images à un système de pilotage.
C'est pourquoi nous avons mis en place un mécanisme de communications assez général (LAD : LAMA communication Daemon) pour assurer le dialogue entre des systèmes aussi différents qu'un moteur de pilotage, une bibliothèque de programmes, une interface utilisateur, un système d'interprétation, un système d'apprentissage, etc. Dans la continuité des travaux de [1], nous avons développé une première version d'un mécanisme de communications sur le principe des bus logiciels, basé sur des communications par sockets Unix TCP.
L'architecture du mécanisme de communication, de type client/serveur, est constituée d'un serveur de messages et d'un module d'émission/réception de messages par processus client. Le serveur de messages est chargé d'aiguiller les communications entre les différents processus clients qu'il connait, mais reste indépendant du fonctionnement interne des processus et de la sémantique des messages qu'ils s'échangent. Les processus clients se déclarent au serveur par un nom et les éventuels services qu'ils peuvent rendre. Le serveur communique avec chaque processus client du système au moyen d'un module générique d'émission/réception de messages par client.
LAD a été implanté sous forme d'un démon Unix intégrant le serveur de messages et un serveur World Wide Web. L'intérêt est de pouvoir commander le démon à travers un visualisateur WWW. Il est ainsi possible de consulter les processus (services) connectés, de bannir un processus, de stopper les communications, de relancer le démon directement par le visualisateur.
Interfaces graphiques.
Figure 2: Exemple d'interface de visualisation
de base de connaissances.
Nous avons développé une interface graphique optionnelle pour LAMA, permettant de visualiser une base de connaissances sous forme arborescente. Lors de la conception, nous nous sommes particulièrement intéressés aux aspects de communication homme-machine et d'ergonomie.
Il est possible de consulter les opérateurs à différents niveaux de détail, de suivre le flot des données, d'afficher la base de connaissances selon certains critères. Cette interface permet aussi de lancer une résolution et de visualiser le plan exécuté. Il est également possible de consulter a posteriori les données produites aux différentes étapes du plan.