Nous allons au cours de cette section illustrer les capacit´es multi-agents et dyna-miques d’AR´eVi. Nous pr´esenterons tout d’abord la mod´elisation d’un m´ecanisme simple. Nous pr´esenterons ensuite une version multi-agents des r´eseaux de Petri. Enfin, nous mon-trerons comment on peut tr`es simplement coupler les deux univers pr´ec´edents grˆace `a la surd´efinition de m´ethodes d’instance.
A.5.1 Les trains d’engrenages
Nous souhaitons mod´eliser un train d’engrenages. Le probl`eme ici n’est pas de r´ealiser une mod´elisation physique (contact entre les dents . . . ) mais une mod´elisation fonction-nelle : deux engrenages en contact tournent en sens contraire, le rapport des vitesses angulaires ´etant identique au rapport des rayons.
Le probl`eme peut ˆetre abord´e d’un point de vue global : le train comporte quatre engrenages : l’engrenage 1 tourne dans le sens des aiguilles d’une montre, le 2 dans le sens inverse etc. Il peut ˆetre abord´e de mani`ere locale : un engrenage E est un objet (passif). Il connaˆıt son successeur et son pr´ed´ecesseur dans le m´ecanisme. Il peut ˆetre sollicit´e (appel de m´ethodes) par son pr´ed´ecesseur P . P indique alors `a E de combien il vient de tourner ainsi que ses caract´eristiques. E `a alors pour charge de d´eduire sa propre rotation et la transmet `a son successeur, le processus se r´epercutant de proche en proche. On cr´ee ensuite un agent moteur (c’est le seul agent de cet exemple) dont le comportement (la m´ethode main) est de tourner. Il ne reste plus qu’`a “connecter” le moteur au premier pignon pour que toute la chaˆıne se mette en marche. Dans le code du destructeur de la classe Pignon, on demande au pignon tu´e de se d´econnecter de son pr´ed´ecesseur. Ainsi, si en cours d’ex´ecution, un pignon est tu´e par un utilisateur, cela ne provoquera pas d’erreur (le pignon pr´ec´edent ne transmet plus de mouvements) et les pignons suivants s’arrˆeteront automatiquement, n’´etant plus sollicit´es par personne. On obtient donc bien un syst`eme dont le comportement est conforme `a son ´equivalent r´eel.
L’exemple pr´ec´edent met en œuvre des engrenages passifs, qui sont des objets mais pas des agents. Afin d’obtenir un univers plus r´ealiste, on peut leur fournir un compor-tement :
– Scruter l’univers.
– Lorsque qu’un engrenage E est d´etect´e `a proximit´e (la somme de son rayon et du rayon de E = la distance s´eparant les deux entit´es) :
– Se connecter `a E
⇒ On se met automatiquement `a tourner.
– Si on est connect´e `a un pignon et que la distance `a celui-ci devient trop importante – Se d´econnecter
⇒ On s’arrˆete automatiquement de tourner.
AR´eVi
On peut donc maintenant interactivement en d´epla¸cant les engrenages, `a l’aide d’un p´eriph´erique d’interface (souris ou autre), modifier le m´ecanisme alors que celui-ci est en mouvement (voir figure A.4).
Figure A.4: Train d’engrenages dynamique.
A.5.2 Les r´eseaux de Petri
Le deuxi`eme exemple d’univers que nous allons pr´esenter concerne les r´eseaux de Petri. Ce type de syst`eme ne poss`ede habituellement pas de repr´esentation graphique mais nous lui en avons n´eanmoins donn´e une afin de visualiser son fonctionnement (voir figureA.5).
Remarque : il existe plusieurs approches pour la programmation de r´eseaux de Petri. Utilisant oRis, nous avons opt´e pour une approche agent : les places les liens et les marques sont des objets, les transitions sont des agents. Elles d´ecident elles-mˆemes quand elles doivent s’activer.
A.5.3 Couplage engrenages et r´eseau de Petri
L’´etape suivante consiste maintenant `a regrouper les deux exemples pr´ec´edents afin que le r´eseau de Petri serve de partie commande aux engrenages qui joueront donc le rˆole de partie op´erative.
Les deux univers ont ´et´e con¸cus s´epar´ement et donc ne se connaissent pas. Le cou-plage est r´ealis´e en trois ´etapes :
Exemples
Figure A.5: Repr´esentation graphique d’un r´eseau de Petri
2. Alors que les engrenages fonctionnent, chargement des r´eseaux de Petri. Les deux univers coexistent en m´emoire et poss`edent leurs propres fenˆetres d’affichage. 3. D´eclenchement d’une commande sur une des places du r´eseau : sur l’entr´ee d’une
marque, on d´emarre le moteur coupl´e aux engrenages, sur la sortie d’une marque, on coupe ce mˆeme moteur.
Le point 3 est r´ealis´e en entrant dynamiquement (sans arrˆeter le syst`eme) le code suivant (figure A.6) :
Ce code surd´efini les m´ethodes d’ajout et de suppression de la Place 2. Les m´ethodes ne sont pas surd´efinies au niveau de la classe (et donc pour toutes les instances) mais uniquement au niveau d’une instance particuli`ere qui donc se singularise et adopte un comportement diff´erent des autres.
Remarque : lors de la surd´efinition d’une m´ethode d’instance, il est toujours possible d’appeler la m´ethode de classe (appel par exemple de Place::add() dans Place.2::add()). Ceci permet tr`es simplement de rajouter une action suppl´ementaire au comportement par d´efaut propos´e par la classe.
A.5.4 Autres exemples d’applications
Le syst`eme AR´eVi a ´et´e utilis´e dans le cadre de contrats industriels :
– Etude de l’ergonomie de locaux techniques : DCN Brest, projet “Charles de Gaul-le”.
– Visualisation 3D de fonds marins : Ifremer, projet “CARA¨IBE 3D”.
AR´eVi
void Place.2::add(agent mark) { { wakeUp(Moteur.1) ; } Place::add(mark) ; } {
agent mark = Place::del() ;; {
sleep(Moteur.1) ; int Place.2::del(void)
}
return (mark) ;
Surdéfinition de la méthode add de l'instance 2 de la classe Place
On démarre le moteur lorsque la place contient au moins une marque
On stoppe le moteur lorsque la place 2 est vide if (!_marks)
if (!_marks)
Appel de la méthode add de la classe Place (commune à toutes les instances)
Conclusion et perspectives
– Repr´esentation 3D interactive du quai Malbert (port de commerce de Brest) : Communaut´e urbaine de Brest, projet “Images et Am´enagement”.