Interactions entre Composants pour des Systèmes Multi

Interactions entre Composants pour des Systèmes Multi-Agents :
Application au Trafic Routier
Sami KHALFAOUI – Wided LEJOUAD CHAARI
Pôle GRIFT Laboratoire CRISTAL
Ecole Nationale des Sciences de l’Informatique
Campus universitaire La Manouba
2010 La Manouba - Tunisie
[email protected] - [email protected]
Résumé
Actuellement les systèmes informatiques sont de plus en
plus complexes, souvent répartis sur plusieurs sites et
constitués de logiciels en interaction entre eux ou avec
des êtres humains. Le besoin d’utiliser la technologie
agents s’est fait ressentir et les évolutions dans ce
domaine sont remarquables. Dans ce contexte, les
applications à base d’agents doivent aussi bien s’adapter
aux modifications de l’environnement et à l’évolution des
interactions qu’aux retrait et ajout de nouveaux
composants. Dans ce papier, nous décrivons certains
travaux sur les interactions logicielles et la
programmation par composants et leur utilisation dans
un environnement agent dynamique. Nous illustrons notre
approche par une application de trafic routier.
1. Introduction
Ces dernières années, les applications à base d’agents
sont utilisées dans de multiples domaines et sont devenues
de plus en plus complexes et distribuées. Les Systèmes
Multi-Agents (SMA) actuels doivent fournir des
environnements très dynamiques qui s’adaptent aux
fréquents changements pouvant se produire au cours d’une
exécution comme dans le cas d’un simulateur de trafic
routier.
La dynamicité est un élément indispensable pour
répondre aux besoins des nouvelles applications. Grâce
aux progrès technologiques autour des communications
réseaux (sans fil ; ATM), les besoins applicatifs se
recentrent autour d’une prise en compte rapide du
contexte d’exécution afin d’adapter les fonctionnalités
offertes par les applications à la situation en cours. Si on
prend l’exemple d’une application de trafic routier, le
contexte d’exécution peut impliquer la mise en place
d’interactions spécifiques (délestage, mise en place de
secours…), en cas d’accidents, de catastrophes naturelles
qui ne devraient pas nécessiter l’arrêt de l’application.
Nous retrouvons aussi dans ce même esprit, les
applications de simulation qui nécessitent de tester
différentes situations d’interactions sans arrêter
l’application. Cependant ce besoin n’a pas fait l’objet de
beaucoup de travaux, et les travaux qui se sont intéressés à
la dynamicité dans les systèmes multi-agents comme [1],
[2], [3] et [4] n’offrent pas la possibilité de gérer
dynamiquement les interactions entre agents.
Vu la maturité qu’a pu atteindre le monde objet et
composant, le besoin de dynamicité et d’évolutivité a été
déjà soulevé et plusieurs travaux ont été menés en ce sens
[5]. Dans cet article, nous allons montrer comment les
résultats obtenus dans le domaine des applications
réparties construites à base de composants peuvent être un
atout dans la réalisation de SMA dynamiques et
hétérogènes. En particulier, nous nous focalisons sur les
résultats de l’équipe RAINBOW qui consistent en
l’utilisation d’un
serveur
d’interactions appelé
« NOAH » et un langage « ISL » pour la définition, la
pose et la destruction des interactions entre composants en
cours d’exécution.
L’organisation de l’article se présente comme suit :
dans la section 2, nous faisons le tour des travaux sur les
SMA ainsi que les travaux sur les composants qui
présentent un intérêt pour notre travail et nous montrons
comment les composants et leurs interactions apportent
des réponses aux systèmes multi-agents actuels. Dans la
section 3, nous présentons la simulation du trafic routier.
La section 4 montre l’illustration de notre approche par la
simulation. Enfin, nous concluons en reprenant les
principales idées exposées tout au long de cet article et en
présentant les perspectives de nos travaux.
2. Travaux sur les SMA et les Composants
Dans cette section, nous décrivons les travaux effectués
pour l’adaptabilité des environnements agents. Puis, nous
passons en revue les travaux sur les composants qui
présentent un intérêt pour notre travail.
2.1. Principaux travaux sur la dynamicité des
SMA
Les auteurs dans [1] proposent un modèle dynamique
d’interactions pour les SMA. Le principe est de soulager
l’agent de certaines tâches d’interaction et de les
transférer à une sorte de messager. Ce messager peut
manipuler, dynamiquement, le message de différentes
manières : trouver le bon destinataire dans le cas où
l’adresse est incorrecte, donner une meilleure présentation
du message, s’assurer que le message sera bien interprété
par le destinataire (ajouter des informations
supplémentaires au message d’origine). Aussi, l’utilisation
du messager facilite-t-elle l’interaction entre agents
hétérogènes. Ce travail se place dans le même contexte
que [6] qui propose l’utilisation d’un agent spécialisé pour
prendre en charge la communication entre les autres
agents.
Le travail présenté dans [2] résout dynamiquement le
problème d’interopérabilité des protocoles en utilisant un
agent intermédiaire appelé proxy qui s’intercale entre les
agents participant à une conversation. Le proxy doit
implémenter un protocole assez générique pouvant être
adapté aux autres protocoles.
En ce qui concerne l’évolutivité des SMA, [4] propose
une plate-forme générique de simulation SIMENV
permettant de construire des simulations à base d’agents
hétérogènes communicants via des canaux de
communications et de faire évoluer dynamiquement le
système par l’ajout et la suppression d’agents et de canaux
de communication entre agents en cours d’exécution. Ces
agents et ces canaux de communication doivent être
prévus à l’avance.
Nous remarquons que peu de travaux se sont intéressés
à l’ajout, la modification et la suppression d’interactions
en cours d’exécution, ou encore, l’ajout, dynamiquement,
d’un agent non prévu à l’avance. Ainsi, l’idée de la
dynamicité dans les SMA mérite d’être creusé davantage.
C’est pourquoi nous nous sommes tournés vers le monde
objet et composant qui, quant à lui, a su donner des
éléments de réponse dans ce domaine.
Dans le paragraphe suivant nous présentons brièvement
des travaux sur les interactions entre composants qui
pourraient être appliqués aux SMA pour améliorer
l’évolutivité des applications.
2.2. Composants – Interactions et dynamicité
Les interactions étant omniprésentes dans le monde
réel, différents travaux ont pris en charge leur
spécification et leur mise en oeuvre dans la communauté
des développements d’applications à base de composants.
Leur présence permet essentiellement de mieux décrire les
assemblages au déploiement d’une application ou
dynamiquement à l’exécution lorsque l’on souhaite
adapter une application.
Les principaux concepts sous-jacents aux ADLs
(Architecture Description Language) sont les composants
et les connecteurs assemblés à l’aide de configurations
[7]. Une configuration architecturale définit la structure de
l'architecture d'une application au travers d'un graphe de
composants et de connecteurs. Les langages de
configuration visent par exemple à exploiter les
descriptions d'architectures pour produire en partie
l'implantation des composants ou pour supporter, au
moins partiellement, le déploiement des applications. Le
dernier-né de ces langages est le Component Assembly
Descriptors du CORBA Component Model, qui permet
une automatisation du déploiement. Certains de ces
langages ont intégré une dimension dynamique permettant
de préciser les évolutions possibles d’une application
comme, par exemple, l'ajout ou le remplacement de
composants et de connexions à l'exécution [8].
Le développement d’applications sur des plates-formes
à composants « standards » tels que EJB [9], CCM [10]
ou .Net [11], force à prévoir a priori les interactions au
niveau des interfaces et du code métier des composants.
Par le modèle de composants, CORBA permet d’intégrer
au composant la réactivité aux perturbations du système.
Néanmoins, celles-ci doivent être prévues statiquement, et
la connectique (comment réagir à la présence d’un
événement dans une source, quel événement produire dans
un puits, etc.) reste à la charge du programmeur des
composants [12]. Certains services (événements,
notifications), l’utilisation de scripts, d’intercepteurs
CORBA [13] ou les conteneurs ouverts [14] se présentent
également comme des technologies permettant
d’implémenter les interactions. Aussi, la part de
connectique et de contrôle induite par les interactions
(synchronisation, conditionnelle, etc.) est-elle toujours à la
charge du programmeur et dépend donc des plates-formes
cibles. La programmation par aspects ([15], [16], [17])
propose également d’expliciter les interactions.
Néanmoins leur mise en œuvre en terme de réception et
émission de requêtes rend non « naturelle » l’écriture de
ces interactions.
Ces techniques sont essentielles à la réalisation d’une
adaptation dynamique des composants, mais il est
nécessaire de les abstraire pour faciliter leur
programmation et aller vers des systèmes plus sûrs. Les
travaux de l’équipe RAINBOW (http://rainbow.essi.fr)
autour de NOAH [5], quant à eux, considèrent les
interactions comme des entités de première classe. Les
interactions sont ainsi décrites dans des schémas
d’interactions. Ces schémas d’interaction, écrits en ISL
(Interaction Specification Language), sont définis
indépendamment des implémentations en se basant sur les
interfaces des composants.
Aussi est-ce sur la base de ces travaux que nous allons
proposer de rendre les SMA dynamiques et évolutifs. La
démarche que nous proposons permet une gestion
dynamique des interactions par l’ajout, la modification et
la suppression des interactions entre agents sans arrêter
l’application. Cette démarche permet aussi d’ajouter des
agents, qui n’ont pas été prévus lors de la conception, en
cours d’exécution.
3. La simulation du trafic routier
Pour mettre en œuvre et valider notre approche, nous
nous sommes basés sur une simulation de trafic routier.
Cette application est développée sous la plate-forme
agents JADE [20]. Dans ce qui suit, nous mettons l’accent
sur le caractère dynamique de la simulation. Par la suite,
nous proposons une description des agents puis nous
dégageons les besoins d’une telle application en terme de
dynamicité.
3.1. Pourquoi une simulation de trafic routier
Le trafic routier est caractérisé par des changements
très fréquents de situations qui peuvent être simples,
complexes voire difficiles à gérer et à contrôler. De plus,
plusieurs événements peuvent se produire comme des
accidents, des travaux, le passage des secours, le passage
de personnalités, … Ces événements peuvent dégrader les
conditions de la circulation et même la bloquer.
L’objectif d’une telle simulation est de contrôler le
trafic routier dans la mesure où la prise de décision
dépend des résultats de la simulation, d’assurer la fluidité
du trafic en anticipant sur les situations de congestion et
de blocage, de trouver des solutions à des situations
complexes du trafic routier, d’avoir un rôle explicatif des
raisons de certaines situations comme les accidents et de
faire des statistiques sur les périodes et les zones délicates
pour des solutions à plus long terme. Le choix d’une
simulation de trafic est justifié par le fait qu’une telle
application se caractérise par :
-
Une forte dynamicité : dans la mesure où les agents
participant à la simulation changent continuellement
d’états. Par exemple, un agent Conducteur peut
avancer, freiner, négocier son passage avec d’autres
agents, des voies peuvent être bloquées ou coupées,
des feux peuvent être hors service, des accidents et des
catastrophes naturelles peuvent se produire, etc. Les
agents sont souvent amenés à interagir pour éviter les
conflits et atteindre leurs buts.
-
De l’évolutivité : dans la mesure où, pour pouvoir
simuler certaines situations, nous devons ajouter ou
supprimer des agents. Par exemple, ajouter un grand
nombre d’agents Conducteur pour simuler une
situation de congestion. Les interactions entre agents
sont aussi amenées à évoluer. Par exemple, ajouter un
nouveau type d’interactions entre agents Conducteurs
en référence à une nouvelle loi du code de la route.
De plus, l’évolutivité de l’état des agents dans un
environnement de circulation routière doit être prise en
charge au cours de l’exécution de la simulation. Ceci
permet un gain en temps et une meilleure réactivité aux
utilisateurs de la simulation.
3.2. Description des agents
La simulation de trafic routier fait intervenir au moins
les classes d’agents suivantes : l’agent Conducteur qui est
l’acteur principal de la simulation. Cet agent cherche à
atteindre son point d’arrivée à partir d’un point de départ
tout en évitant les situations de conflit. Plusieurs types
d’agents Conducteurs peuvent exister, par exemple,
Conducteurs non disciplinés, les Conducteurs spéciaux
(ambulances, voitures de police,etc.) , etc. Chaque type de
ces agents Conducteurs présente un comportement
spécifique. L’agent Environnement sert à représenter
graphiquement la simulation et à fournir aux agents
Conducteurs
des
informations
générales
sur
l’environnement. L’agent Carrefour est lié à un carrefour
donné et contrôle les Conducteurs présents au niveau de
ce carrefour. Il existe plusieurs types d’agent Carrefour
selon que le carrefour est contrôlé par des feux, des
panneaux de signalisation, ou bien, il s’agit d’un carrefour
simple. L’agent Voie concerne une voie donnée. De
même, il existe plusieurs types d’agents Voies selon le
type de la voie en question : avec feux, avec panneaux de
signalisation, ou bien, voie simple. Le rôle de cet agent est
de contrôler les Conducteurs se trouvant sur la voie. Et,
l’agent Policier qui a une hiérarchie supérieure et qui
intervient au niveau des carrefours pour gérer le passage
des Conducteurs.
3.3. Besoins d’une nouvelle approche
Notre application présente plusieurs besoins de
dynamicité. Certains de ces besoins peuvent être pris en
charge par la plate-forme agent, d’autres pas. En effet,
lors d’une simulation, nous pouvons avoir besoin de
rajouter de nouveaux agents à la simulation pour la rendre
plus complexe et observer le comportement qui en résulte.
Cette opération est prise en charge par les plates-formes
agent actuelles, à condition que le nouvel agent ajouté soit
prévu à l’avance et développé avec le SMA. Par exemple,
il est possible de rajouter, au cours d’une simulation, des
agents Conducteurs pour tester différentes situations de
trafic. Ceci est aussi valable pour la suppression.
Cependant, il se peut que lors d’une simulation, nous
ayons besoin d’intégrer un nouvel agent qui n’était pas
prévu lors du développement du SMA. Par exemple, nous
voulons intégrer l’agent Piéton dans la simulation. Ce type
d’ajout n’est pas faisable, dynamiquement, avec les platesformes agents actuelles. Ceci est dû principalement au fait
que le code de la communication est intégré dans le code
de l’agent. Il faut donc, arrêter le SMA, développer le
nouvel agent en tenant compte de ses interactions avec les
autres agents et modifier le code des agents qui seront en
interaction avec ce nouvel agent.
Aussi, au cours d’une simulation, il serait opportun, de
pouvoir rajouter, modifier et supprimer des interactions.
Par exemple, nous voulons rajouter une nouvelle
interaction entre des agents Conducteurs qui énonce que
lorsqu’un Conducteur s’arrête trop longtemps, son
poursuivant klaxonne et les deux conducteurs entament
une négociation.
Dans une simulation, la fréquence d’ajout de nouveaux
agents et la fréquence d’ajout, de modification et de
suppression d’interactions entre agents peuvent être
importantes. Le fait de devoir, à chaque fois, arrêter la
simulation, modifier le code des agents, puis relancer
l’application, peut engendrer un surcoût de temps
considérable. Ceci fera perdre à la simulation tout son
intérêt, surtout si elle est utilisée comme un moyen de
décision d’urgence. Ces objectifs ne sont pas encore
atteints par les plates-formes agents actuelles.
Ainsi, l’approche basée sur les interactions introduit :
(1) une nouvelle architecture interne des agents, (2) une
nouvelle manière pour modéliser les SMA. En effet, nous
rappelons que l’architecture interne d’un agent (voir
Figure1) est représentée par:
- Des rôles : que fait un agent.
- Des compétences : ces compétences peuvent être
internes, c’est à dire, comment l’agent assure ses
rôles et des compétences externes (sociales)
concernant ses interactions.
- Des interactions : permettant à un agent de
communiquer.
Figure 1. Architecture interne d’agents
L’approche par interactions que nous proposons (voir
Figure 2) dissocie les interactions de l’architecture interne
de l’agent. Ces interactions, désormais gérées par le
serveur NOAH, définissent aussi le comportement social
des agents. Le comportement social d’un agent correspond
à son comportement par rapport aux autres agents du
SMA. Par exemple, le comportement de l’agent
Conducteur en présence des agents Feu. Dans une
architecture classique, ce comportement est défini à
l’intérieur de l’agent. Dans l’approche par interactions, il
est défini dans l’interaction qui relie un agent Conducteur
à un agent Feu. De plus, une politique d’arbitrage et de
prise de décision peut être définie dans l’agent pour la
gestion de ses propres comportements et ceux définis par
les interactions.
4. Une approche basée sur les interactions
entre composants pour les SMA
Dans cette section, nous présentons une approche à
base d’interactions entre composants et nous montrons
son adaptation au monde des agents.
4.1. Présentation de l’approche
Notre approche consiste à dissocier les interactions
entre agents du code métier des agents et à déléguer la
gestion de ces interactions, désormais exprimées dans le
langage ISL, à un serveur d’interactions appelé NOAH.
Les agents seront gérés par la plate-forme JADE.
Figure 2. Nouvelle architecture d’agents
Dans la modélisation des SMA, les approches sont, en
majorité, orientées agent, c’est à dire que l’agent est au
centre du développement. Par contre, notre approche est
basée sur les interactions, c’est à dire que, l’application
est construite à partir des interactions exprimées en ISL.
Le développement des SMA suit désormais la démarche
suivante :
- Etape 1 : Dans la première étape du développement
nous nous intéressons à la construction des classes
d’agents et la description de leurs compétences sans se
préoccuper des interactions entre eux. En d’autres
termes, nous ne décrivons que ce que l’agent sait faire
sans se préoccuper de sa communication : avec qui,
quand et comment communique-t-il, etc.
-
-
Etape 2 : Dans cette étape, nous développons des
modules de communication permettant de mettre en
interaction
les
différentes
classes
d’agents
précédemment développées. Ces modules de
communication sont des schémas d’interaction
exprimés en ISL. Les schémas d’interaction sont basés
sur les interfaces des agents.
Etape 3 : La dernière étape consiste à poser les
interactions entre les agents en instanciant les schémas
d’interaction. Ces interactions sont gérées par le
serveur d’interactions NOAH.
En utilisant la plate-forme JADE, ces interactions
correspondent à des échanges de messages FIPA-ACL. En
effet, pour le premier scénario, quand C1 s’arrête, il
envoie un message à C2 lui informant de son nouvel état
et ce dernier adaptera son comportement en fonction du
message reçu (s’arrêter ou continuer à rouler). De même
pour le second scénario, si C1 avance (après s’être arrêté),
il informe C2 par un message FIPA-ACL et ce dernier
adaptera son comportement en fonction du message reçu.
Si nous voulons ajouter une autre interaction entre ces
deux Conducteurs telle que, si le premier Conducteur
s’arrête trop longtemps, alors le second klaxonne. Dans ce
cas, il faut arrêter le SMA, modifier le code des deux
agents Conducteurs pour intégrer la nouvelle interaction
puis relancer le SMA.
Reprenons le même exemple avec l’approche basée sur
les interactions. Les interactions entre les deux agents
Conducteurs sont décrites dans le schéma d’interaction
suivant :
interaction
suivreConducteur(Conducteur
cond,
Conducteur poursuivant)
{
cond.arret() cond._call1 ;
if cond.calculDistance(poursuivant.
getPosition()) < distanceSecurite) then
poursuivant.arret()
end if
Nous avons repris l’application de simulation de trafic
routier en utilisant l’approche à base d’interactions pour
montrer la faisabilité ainsi que l’intérêt de cette dernière.
Prenons l’exemple de deux véhicules qui se suivent sur
une même voie (voir figure 3).
poursuivant.avancer()
if (poursuivant.calculDistance(cond.
getPosition()) < distanceSecurite) then
poursuivant.arret ()
else
poursuivant._call
end if
Voie 1
cond.avancer()cond._call;
if (poursuivant.stop ()) then
C2
C1
Figure 3. Situation de deux véhicules qui se suivent
Ces deux agents Conducteurs interagiront selon
différents scénarii :
- Si le premier Conducteur C1 s’arrête et que la distance
qui le sépare du second C2 est inférieure à la distance
de sécurité alors, C2 s’arrête.
- Si C1 avance et que C2 était à l’arrêt alors, ce dernier
avance aussi.
poursuivant.avancer()
end if
}
Une interaction à partir de ce schéma d’interaction est
dynamiquement créée pour relier deux agents
Conducteurs dès que ces agents se suivent sur une même
voie. Cette interaction est dynamiquement supprimée si
ces Conducteurs ne se suivant pas.
Avec l’approche à base d’interactions, il est désormais
possible de rajouter une nouvelle interaction (par
exemple, klaxonner) en cours d’exécution. En effet, il faut
commencer par définir le schéma d’interaction qui sera
1
Dans ISL « _call » sert à exécuter la méthode qui a déclenché la règle
d’interaction.
dynamiquement instancié pour créer l’interaction entre les
deux agents Conducteurs.
La possibilité d’ajouter une interaction en cours
d’exécution rend possible l’ajout dynamique d’agents non
prévus dans le SMA. En effet, pour intégrer un nouvel
agent dans un SMA, il faut développer la classe du nouvel
agent puis la lancer via la plate-forme agent. Par la suite,
il suffit de lier cet agent aux autres agents du SMA à partir
des schémas d’interactions qui auraient été décrits pour
exprimer sa communication avec les agents du système.
Dans ce qui suit nous présentons les principaux apports
de l’approche basées sur les interactions pour les SMA.
4.2. Apports de l’approche basée sur les
interactions
Les apports de l’approche basée sur les interactions
peuvent être résumés en deux points :
- L’expression des interactions à un niveau plus abstrait,
c'est-à-dire qu’on ne manipule plus des interactions mais
plutôt des schémas d’interaction. Ceci permet une
gestion dynamique des interactions entre les agents.
- La réduction de la complexité : cet apport découle de la
fusion des règles d’interaction. Il s’agit de la répartition
d’un comportement donné sur plusieurs règles
d’interaction. Dans l’approche agent, pour décrire un
comportement, nous devons prendre en compte toutes
les conditions et toutes les actions dès le départ. Dans
certains cas, cette opération s’avère délicate et peut
mener à l’erreur et la confusion. De plus, lors de l’ajout
d’une nouvelle condition ou d’une nouvelle action, nous
sommes obligés de modifier le code du comportement,
opération délicate lorsque le comportement est
complexe. Cependant, avec la nouvelle approche, nous
ne sommes plus obligés d’exprimer toutes les conditions
et toutes les actions à l’avance mais celles-ci sont
réparties sur les différentes règles d’interactions, ce qui
réduit la complexité dans la description des
comportements et facilite la mise à jour du code en
localisant la modification. Les règles d’interaction sont
par la suite automatiquement fusionnées pour donner un
comportement global équivalent. Quel que soit l’ordre
dans lequel les règles sont fusionnées, le comportement
résultant est toujours le même. Ceci est dû au fait que la
fusion est associative et commutative. Les principes de
la fusion sont détaillés dans [21].
Soit le schéma d’interaction suivant :
interaction rencontrerFeux(Conducteur cond, Feux
feu)
{
cond.avancer()
if(feu.getCouleur.equals(“rouge”)) then
cond.arret()
else
cond._call
end if
feu.changeCouleur()
if(feu.getCouleur().equals(“vert”)&&
cond.stop()) then
cond.avancer()
end if
}
Ce schéma d’interaction relie un agent Conducteur à un
agent Feu. Selon ce schéma d’interaction, un agent
Conducteur ne peut avancer que si le Feu est au vert. Une
interaction à partir de ce schéma d’interaction est posée
dynamiquement lorsqu’un Conducteur entre dans un
carrefour géré par des Feux. Cette interaction est
supprimée dynamiquement lorsque ce Conducteur quitte
le carrefour.
A partir des deux schémas d’interaction décrits plus
haut (recontrerFeu, suivreConducteur), nous remarquons
que la méthode avancer() se trouve impliquée dans deux
règles d’interaction. Ces règles seront fusionnées pour
donner la règle équivalente suivante :
cond.avancer()
if(feu.getCouleur().equals(“rouge”) then
conducteur_1.arret()
else
cond._call;
if(poursuivant.stop()) then
poursuivant.avancer()
end if
end if
5. Conclusion
Dans ce papier, nous avons souligné un besoin de
rendre les systèmes multi-agents plus dynamiques et plus
évolutifs. Nous avons proposé une approche offrant une
nouvelle architecture interne des agents ainsi qu’une
nouvelle modélisation des SMA. Cette approche permet
de poser, modifier et détruire les interactions entre agents
en cours d’exécution, chose qui nécessitait l’arrêt de
l’application et la modification du code des agents. Elle
offre aussi la possibilité d’intégrer dynamiquement un
nouveau type d’agents non prévu à l’avance. Pour réaliser
ce travail nous avons utilisé le langage ISL pour la
définition des interactions et le serveur d’interaction
NOAH pour les gérer, tous deux issus des travaux de
l’équipe RAINBOW sur les interactions entre les
composants. Nous avons validé notre approche et vérifié
sa faisabilité à travers un exemple d’une simulation de
trafic routier.
Comme perspectives de notre travail, nous pensons
appliquer l’approche par interactions, non plus à des
interactions simples et séparées, mais à des protocoles
d’interactions plus élaborés et plus complexes moyennant
le concept de fusion des règles d’interaction. Nous
projetons aussi d’utiliser cette approche pour définir une
bibliothèque générique d’interactions pour le trafic routier
ou toute autre application du même type (par exemple, le
contrôle du trafic d’un réseau informatique). Nous
songeons aussi à une meilleure intégration de l’approche
par interactions au niveau des plates-formes agents.
L’objectif à plus long terme étant de concevoir et
développer une plate-forme agents basée sur les
interactions logicielles.
6. Bibliographie
[1] A. Ribeiro, Y. Demazeau, « A Dynamic Interaction Model
for Multi-Agent Systems », 1998.
[2] D. Jouvin, S. Hassas, « Architectures dynamiques de
systèmes multi-agents conversationnels », Journée Francophone
des Systèmes Multi-Agents, 2003.
[3] J. Quenum, A. Slodzian, S. Aknine, « Configuration
automatique de modèles d’interaction d’agents », Journée
Francophone des Systèmes Multi-Agents, 2003.
[4] D. Meyer, C. Buchta, « SIMENV: A Dynamic Simulation
Environment for Heterogeneous Agents », 2003.
[5] M. Blay-Fornarino, D. Ensellem, A. Occello, A. Pinna-Dery,
M. Riveill, J. Fierstone, O. Nano, G. Chabert, «Un service
d’interactions : principes et implémentation », Journée des
Composants, 2002.
[6] W. Lejouad-Chaari, F. Mouria-Beji, « High level
commununication protocol in a distributed multiagent system »,
11th Intenational Conference on Indistrial and Engineering
Applications of Artificial Intelligence end Expert Systems,
Spain, June 1998.
[7] N. Medvidovic, R. Taylor, « A Framework for Classifying
and Comparing Architecture Description Languages», European
Software Engineering Conference (ESEC/FSE 97), 1997, pp. 6067.
[8] A. Senart, M. Riveill « Aspects dynamiques des langages de
description d'architecture logicielle », Numéro spécial de la
revue L'OBJET : Coopération dans les systèmes à objets, 2002,
pp. 109-129.
[9] Enterprise Javabeans Specification Version 1.1, Sun
Microsystem Inc, janvier 2000.
[10] R. Marvie, M. Pellignini, « Modèles de composants, un état
de l’art», Numéro spécial de L’Objet, vol. 8, no. 3, Hermès
Sciences, Coopération dans les systèmes à objets, 2002.
[11] R. Jeffrey, Applied Microsoft .Net Framework
Programming, MS Press, ISBN 0735614229, 2002.
[12] L. Berger, « Support des interactions dans les systèmes
objets et componentiels », Numéro spécial de L’OBJET :
Coopération dans les systèmes à objets, vol. 7, 2001-2002.
[13] OMG, CORBA 2.4.2 Interceptors chapter, OMG Document
formal/01-02-57, février 2001.
[14] M. Vadet M., P. Merle, « Les conteneurs ouverts dans les
plates-formes à composants », Journées Composants 2001,
Besançon, 25-26 octobre.
[15] R. Pawlak, L. Seinturier, L. Duchien, G. Florin, « JAC: A
Flexible Framework for AOP in Java », Reflection'01, Kyoto,
Japan.
[16] M. Riveill, E. Bruneton, « JavaPod: An Adaptable and
Extensible Component Platform », RM’2000, Workshop on
Reflective Middleware, New York, USA, April 2000.
[17] F. Sarradin, T. Ledoux, « Adaptabilité dynamique de la
sémantique de communication dans Jonathan », Colloque
Langages et Modèles à Objets (LMO’01), Hermès Science,
L’objet-7/2001, Le Croisic, France, janvier 2001.
[18] F. Bellifemine, G. Caire, T. Trucco, G. Rimassa, Jade
Programmer’s Guide , JADE 2.5, 2002.
[19] The FIPA ACL Message Structure Specifications, 6
décembre 2002.
[20] S. Khalfaoui, « Interactions logicielles pour des SMA
dynamiques et évolutifs », Rapport de Mastère, ENSI-Tunis,
Janvier 2004.
[21] L. BERGER, « Mise en oeuvre des interactions en
environnements distribués, compilés et fortement typés: le
modèle MICADO », PhD thesis, Université de Nice, 2001.