Objets, messages et comportements dans Ross
La structure d'un modèle de simulation objets se définit avec des objets, des messages entre objets et des comportements (cf. McArthur 1986: 74ff). La programmation d'un tel modèle se rapproche de près de la façon dont on décrit intuitivement les objets et les processus d'un système dynamique tel que l'on peut l'observer. En effet, beaucoup de systèmes sont d'abord décrits en termes de leur composantes séparées. Une composante d'un système peut en effet se définir par ses attributs et ses comportements possibles. Nous donnerons ici une introduction sommaire à Gnu-Ross (une version "domaine publique").Le comportement du système peut se définir comme l'échange d'informations entre les objets. Les interactions entres objets ROSS se font grâce à une technique appelée "message passing" en informatique. La syntaxe pour passer un message à un objet est la suivante*3:
(ask <objet> <message>) ou le synonyme: (tell <objet> <message>)Un objet Ross peut représenter un acteur (humain ou collectif) ou n'importe quel autre type d'objet. Un message représente n'importe quelle liste de mots que l'objet est capable de comprendre, par exemple:
(tell FirstInstance make decision
with case acquisition-1 by demander Muller)
Notez que l'on peut très bien utiliser n'importe quel mot français à condition que l'objet receveur puisse les comprendre. Lorsqu'un objet reçoit un message, il doit être capable de le comprendre. Le modéliseur doit donc spécifier un comportement-type dont la structure d'activation, c'est-à-dire le chablon correspond (angl.:match) au message, et dont les actions représentent une réponse adéquate. La syntaxe pour définir le comportement d'objet est la suivante:
(ask <objet> when receiving <structure d'activation> <actions>)On demande donc à un acteur de "se" définir un comportement en lui envoyant un message "when receiving .... ". Cet exemple illustre bien l'usage très général du "message passing" au delà de la simulation proprement dite. La structure d'activation est une liste de symboles qui peut contenir des variables, comme par exemple:
(make decision with case > acquisition by demander > demander)Les symboles précédés par ">" sont des variables. Un message comme "make decision with ...." correspond à cette structure et peut donc activer un comportement. La notion de variable dans une structure d'activation est très importante. En effet, c'est grâce à ce mécanisme que le système peut opérer avec une certaine flexibilité. Ces variables peuvent ensuite être utilisées dans le code du comportement. (c'est-à-dire elles seront remplacées par les valeurs dans le message). Dans notre exemple, "acquisition-1" est la valeur de "acquisition" et "Muller" est la valeur de "demander". La variable myself possède un statut spécial. Il s'agit ici d'une autoréférence à l'objet. On l'utilise par exemple pour envoyer un message à soi-même ou pour envoyer l'identité de l'objet à un autre objet. Les actions du comportement sont déjà plus difficiles à formuler. Dans un cas simple, un corps d'action simple consiste simplement en une suite de messages que l'on envoie à d'autres objets. Voici un exemple simple qui définit un comportement appelé "commander". Lorsqu'il reçoit le message d'envoyer un objet à un endroit, il envoie à cet objet le message d'y aller.
(ask commander when receiving (send > moving-object to > place) (ask ! myself tell ! moving-object go to > place)Examinons un exemple plus difficile: dans ces messages (et en règle générale dans leur corps d'actions), on distingue entre expressions non-évaluées et évaluées. Une expression est en règle générale un simple symbole ou une liste représentant un message dont on veut utiliser la "réponse". Une expression non-évaluée doit être interprétée textuellement, tandis qu'une expression évaluée retourne une valeur utilisée par la suite. Dans Ross, toute expression précédée par un "!" doit être évaluée (de la même façon qu'une valeur remplace le nom d'une variable). Les autres sont interprétées textuellement. On emploie le "!" surtout pour pouvoir utiliser la valeur des variables correspondantes (angl.: "match") à la structure d'activation et pour utiliser le résultat de l'envoi d'un message. Pour pouvoir envoyer un message à l'objet lui-même il faut utiliser la variable "! myself". Voici un exemple tiré de McArthur (86:75):
(send > moving-object object guided by > guider to > whom)
... et un comportement qui lui correspond:
(ask fighter-base when receiving
(send > fighter guided by > gci to > penetrator)
(ask ! myself
schedule after
! ( ask myself recall your scramble-delay) seconds
tell ! fighter chase ! penetrator guided by ! gci)
(ask ! myself add ! fighter to your list of fighters-scrambled)
(ask ! myself remove ! fighter from your list of fighters-available))
Ce comportement s'active donc grâce à un message du type "(send > fighter guided by > gci to > penetrator)" et a pour résultat 3 comportements internes (les 3 "ask ! myself"). Le premier comportement contient deux autres, dont un comportement externe qui lance au bout de quelques secondes un "tell ! fighter chase ! penetrator guided by ! gci" pour instruire un avion chasseur. Ainsi, un comportement modélise donc les façons dont un objet peut répondre à des "inputs" (perceptions, informations, forces) dans le "monde" à modéliser. Ces comportements sont en règle générale spécifiés par rapport à un certain type d'objets. Il n'est donc pas nécessaire de faire ce travail pour chaque objet individuel dont on dispose. Dans un "corps" de comportement, une commande Ross commence par un "ask ...." ou par un "tell..." qui est un synonyme. Ross possède en outre une série d'expressions spéciales entourées de parenthèses comme "(your ....)". Elles ont deux fonctions: (1) certaines rendent la lecture du code plus simple, il s'agit donc d'abréviations. Par exemple (your status) se traduit par (ask myself recall your status). Ce sont en quelque sorte des pronoms conceptuels. Dans Ross, l'utilisateur peut en définir lui-même, dans Gnu-Ross, il faut posséder quelques connaissances en programmation pour le faire. (2) Les autres abréviations sont des constructions de contrôle. Il s'agit là essentiellement de la création de variables temporaires, de conditionnels et de boucles. A la place de ces constructions fournies par Ross, il est bien sûr possible d'utiliser directement des constructions Lisp. Mais ces dernières sont moins claires pour un utilisateur qui ne sait pas programmer.
- Les commandes "create..." permettent de créer un nouvel objet. On peut associer des attributs ("slots") à chaque objet et manipuler leurs valeurs avec les commandes de manipulation d'attributs. On peut par exemple traiter un attribut comme une queue, y rajouter des éléments à la fin et enlever le premier.
- Chaque objet peut également contenir des "faits". Il s'agit d'une liste d'items (des listes d'une profondeur arbitraire) dans laquelle on peut rajouter, enlever, collectionner et rechercher par les commandes de manipulation de la mémoire. Cette "mémoire" est un attribut spécial qui sert à implémenter quelques fonctionalités que l'on retrouve dans les systèmes à bases de règles, comme le "pattern-matching".
- La "mémoire des plans" permet d'enregistrer des commandes (comportements) qui doivent être exécutées à un certain moment.
- Il existe quelques commandes pour faire exécuter un comportement par un autre objet ou encore les attributs d'un autre objet.
;; Creation d'un acteur générique
(ask ross create an instance actor)
;; Creation d'une "Administration"
(ask actor create an instance Administration)
;; Creation d'une "base de données" de cas acceptables
(tell Administration remember (
((Working Permit C) (RealEstateType appartment))
((Working Permit B) (RealEstateType appartment))
))
;; Procédure de décision
;; Lorsqu'un cas se trouve dans la base de données, l'autorisation est
;; accordée, sinon elle est refusée.
(ask Administration when receiving
(make decision with case > case by demander > demander)
(if (ask !myself recall if any items match !case)
(tell !demander remember (Authorization granted))
(tell !demander remember (Authorization refused))
))
;; Simulation d'un "cas"
(ask actor create an instance Muller)
(tell Administration make decision
with case ((Working Permit C) (RealEstateType appartment))
by demander Muller)
Critique et discussion
La critique principale que l'on peut adresser à des langages de type Ross, c'est que le modéliseur doit prévoir et programmer un certain nombre d'actions qui sont inintéressantes au plan conceptuel. Il s'agit d'un problème découlant du phénomène appelé le "frame problem" ou plus largement des "data consistency issues" en intelligence artificielle. Beaucoup d'objets possèdent un certain nombre d'attributs qui dépendent de l'évolution du temps. Cammarata (86:5) et al. leur donnent le nom d'attributs autonomes. En effet, dans nos essais avec ce langage, pour maîtriser ce phénomène, nous avons dû écrire plusieurs comportements Ross pour les objets en question qui leur sont envoyés régulièrement par la montre de simulation. Une autre solution aurait consisté à recalculer ces valeurs au moment où on veut les utiliser. Dans ce cas, tous les comportements ayant besoin d'une valeur auraient dû provoquer ce calcul. Un bon langage de simulation devrait permettre au modéliseur de déclarer des méthodes qui calculent un attribut au moment où quelqu'un a besoin de leur valeur. On parle dans ce cas d'un "if-needed demon". Un autre problème consiste en ce que Cammarata (86: 7) appelle les événements non-intentionnels (ou effets secondaires). Ces événements, comme par exemple le calcul de la distance entre deux objets par un de ces objets ne correspond pas à une action intentionnelle dans beaucoup de cas, mais on en a besoin pour déterminer par exemple si un rpv entre dans la zone active d'un radar. En principe, dans une simulation, on devrait seulement prévoir les activités que l'objet accomplit réellement. Ces calculs devraient être faits d'une façon asynchrone en fonction de l'évolution de certains attributs autonomes. Il est assez difficile de savoir comment interfacer un tel monde de simulation avec une interface graphique. Lorsque l'on possède beaucoup d'objets, il devient impossible d'afficher la position (ou d'autres informations) de chaque objet à chaque pas de simulation. Il faut chercher des méthodes moins gourmandes. Ces trois problèmes ont été résolus en partie dans des extensions du langage Ross utilisées chez Rand. Ross reste assez bien ancré dans la tradition de la simulation des événements discrets.
THESE présentée par Daniel Schneider - 19 OCT 94
