Conception centrée interaction : Application à la conception de simulation interactive Michel Augeraud, Frédéric Collé, David Sarramia Laboratoire L3I Université de La Rochelle F-17042 La Rochelle Cedex1 {michel.augeraud, fcolle, david.sarramia}@univ-lr.fr

RÉSUMÉ .

La complexité des systèmes interactifs résulte de la connaissance partielle que l’on en a. De tels systèmes sont spécifiés par des propriétés locales et leur comportement global est généralement "émergeant". Maîtriser la complexité est un objectif permanent du génie logiciel. La conception orientée objet a donné lieu à plusieurs courants visant à maitriser la complexité : l’approche par aspects visant à séparer les aspects fonctionnels et non fonctionnels, l'approche par point de vues et l'approche par composants. La principale problématique à laquelle se heurte la première est la synthèse des points de vue. L’approche centrée interaction que nous proposons permet d’intégrer une approche par point de vue. La méthode proposée se fonde sur la formalisation de la connaissance des entités actives et passives, des interactions entre entités et de la prise en compte de la réglementation des systèmes étudiés. Une approche multiagents est utilisée dans ce cadre. D'un point de vue décisionnel, notre démarche permet d'évaluer les conséquences de prises de décisions relatives à différents horizons temporels (fermeture de routes, création de parking,...). ABSTRACT .

The complexity of interactive systems results from partial knowledge that someone has on it. Such systems are specified by local properties and their global behavior is generally emerging. Managing the complexity is a permanent objective of the software engineering. Object oriented design has given place to several approaches aiming at controlling complexity: aspect programming which separates functional and non functional aspects, the approach by view points and the approach by components. One of the main problems facing with view points is the synthesis of the view points. Interaction centered approach we propose integrates the use of view points. The method suggested is based on the formalization of the knowledge of the active and passive entities, the interactions between entities and by taking into account of the regulation of the studied systems. An multiagents approach is used within this framework. From a decisional point of view, our approach makes it possible to evaluate the consequences of decision-makings relative to various temporal horizons (closing of roads, creation of carpark...). : Conception multiagents, systèmes multi-agents, conception centrée interaction, rôle, logique linéaire, scénario, calcul des ambients MOTS -CLÉS

KEYWORDS :

Multi-agent design, multi-agent systems, interaction based design, role, linear logic, scenario, ambient calculus

1. Introduction Nous proposons une démarche pour la production d’un environnement logiciel qui s'appuie sur la simulation interactive. L'immersion de l'utilisateur dans une représentation virtuelle du système permet l'évaluation de critères qualitatifs fins et parfois impossibles à mettre en équation. Par exemple, il est difficile voire impossible de mettre en équation la perception du cadre urbain par un piéton, alors qu'il est beaucoup plus facile de demander leur avis à ces piétons. D'un point de vue décisionnel, notre démarche permet d'évaluer les conséquences de prises de décisions relatives à différents horizons temporels (fermeture de routes, création de parking,...). Elle s’intéresse ainsi à la mise en œuvre de différents plans, tel le Plan de Déplacement Urbain. L'adaptation et l'impact de tels plans, coûteux et complexes à mettre en œuvre, font l’objet d’études de faisabilité facilitant la prise de décision. La conception de systèmes multiagents définit un système comme un ensemble d'entités interagissant. Dans cette organisation les entités interagissent et pour chaque interaction, chaque entité joue un rôle. La notion de rôle est liée aux "abstractions organisationnelles" du domaine (Wooldridge et al., 2000). Pour concevoir un système complexe où le nombre d’entité et le nombre d’interaction sont grands on peut réduire la difficulté en utilisant une approche par points de vue. Nous définissons une approche dans laquelle la conception est facilitée par la définition d’interactions. L'expression de ce qu'est le système est une donnée contrainte par des notions de localité, de localité temporelles et de localités spatiales. La démarche de conception que nous proposons, s'appuie sur cette connaissance associant localité et contraintes. La méthode proposée se fonde sur la formalisation de la connaissance des entités actives et passives, des interactions entre entités et de la prise en compte de la réglementation des systèmes étudiés. Une approche multiagents est utilisée dans ce cadre. Un autre point important réside dans la possibilité d’expérimenter des modifications éventuelles sur le système en les réalisant par le biais d'une approche de type jeu, utilisant notamment une trame scénaristique prédéfinie ou non. Ce papier présente une proposition de méthodologie de modélisation répondant aux objectifs précédents. Des exemples illustratifs des différents formalismes utilisés sont fournis en relation avec les Systèmes de Trafic Urbain. La deuxième section présente un état de l’art des méthodes de conception de Systèmes MultiAgents (SMA) les plus répandues. La section suivante énonce les notions d’interaction et de point de vue. Elles sont utilisées comme un apport dans la modélisation des organisations. La méthodologie proposée est décrite dans la quatrième section. Deux étapes de cette méthodologie sont présentées : la première correspond à une modélisation orientée objets et la seconde à une spécification orientée agents. Pour chacune d’entre elles, la description des informations extraites est fournie, les diagrammes UML sont précisés, et des formalismes complémentaires (représentation matricielle) sont donnés. L’architecture de l’environnement logiciel à produire est

également explicitée. Une application partielle de la méthodologie aux Systèmes de Trafic Urbain (STU) est fournie dans la cinquième section.

2. Etat de l’art Les méthodologies traitant de la conception de SMA pour l’étude de système complexe sont nombreuses. La classification et la comparaison de ces méthodes ont suscité la rédaction de nombreux articles, comme par exe mple celui de (Shehory et al., 2001), (Wooldridge et al., 2000), (Tveit, 2000), ou encore celui de (Iglesias et al., 1999). Selon Tveit, elles peuvent être distinguées en des méthodes de haut niveau et des méthodes de conception. Les méthodes de haut niveau proposent un processus descendant de développement de SMA. GAIA (Wooldridge et al., 2000) propose un processus distinguant strictement l’analyse de la conception. Il s’articule autour de six modèles : le modèle des besoins point de départ de l’étude ; deux modèles pour l’analyse (rôles, interactions) et trois modèles pour la conception (agents, services, accointances). Les deux notions de base de GAIA sont le rôle et le protocole. Les agents sont identifiés à partir des rôles et les protocoles spécifient la dynamique des interactions. La génération de code ne fait pas partie des objectifs de GAIA, aucun guide n’est par ailleurs fourni pour une quelconque implémentation du système multi-agent conçu. MaSE (Multiagent Systems Engineering Methodology) (DeLoach, 1999) propose deux phases : une d’analyse (permettant d’obtenir les rôles et les tâches associées) et une de conception (pour obtenir le SMA implanté), proposant au total sept étapes. Prometheus (Padgham et al., 2002) propose également une telle démarche, tout en s’imposant de ne considérer les agents que comme des programmes informatiques. Cette méthode distingue trois étapes (spécification du système, conception de l’architecture et conception du système) et distingue entre autre les aspects dynamiques, les vues globales et les vues détaillées. Son intérêt est de décrire des scénarios d’utilisation du système en lien avec des cas d’utilisation, et d’effectuer en outre un regroupement des fonctionnalités via les données accédées. Prometheus utilise AUML (Odell et al., 2000) comme langage de spécification des protocoles entre agents. RoMAS (Role-based Modeling for MAS) (Yan et al., 2002) travaille sur les rôles et les cas d’utilisation. Elle réutilise la notion de rôle de GAIA et MaSE. RoMAS utilise les cas d’utilisation pour identifier les rôles. Elle ne propose cependant pas de démarche complète comme GAIA et MaSE. Aalaadin (Ferber et al., 1998) est une approche organis ationnelle qui structure un SMA selon le modèle AGR (Agent – Groupe –Rôle). AGR propose un ensemble minimal de concepts permettant d’organiser un SMA en se focalisant sur la notion d’organisation plutôt que sur celle d’agent. La structure organisationnelle est fondée

sur le regroupement conceptuel d'agents en groupes. Un agent peut intervenir dans plusieurs groupes, où il peut jouer différents rôles correspondant à ses activités ou interactions. Aalaadin propose un processus en trois phases (Gutknetch et al., 1999). L’analyse sert à identifier les fonctions du système. La conception permet l’identification des groupes et rôles au travers de diagrammes de structures organisationnelles, ainsi que la description des interactions entre rôles au moyen de diagrammes de séquence. La dernière phase de réalis ation débute par un choix d’architecture d’agent et instancie les structures organisationnelles en organisations concrètes. Cette réalisation peut être supportée par la plate-forme MadKit, autre apport lié à Aalaadin pour rendre opérationnel le modèle AGR. Ainsi, les méthodologies de conception de SMA distinguent toutes l’analyse de la conception, mais ne se situent pas au même niveau. GAIA ne possède pas de spécification formelle des rôles ou des agents. MaSE est guidée par l’implémentation sous la forme de programmes et utilise donc différents formalismes (automate d’états finis, AUML) pour réaliser la validation. La production automatique de code n’est pas encore réalisée mais est envisageable. Mis à part Promotheus, les méthodologies ne traitent pas d’un processus complet allant d’une analyse/spécification du domaine vers la conception/implémentation d’une application. Elles s’intéressent à l’une de ces parties en laissant libre à l’utilisateur d’employer d’autres techniques en complément. Toutes ces méthodes utilisent la notion de rôle et de protocole pour capturer les interactions et les activités des entités du système étudié. Les dernières étapes des méthodologies consistent à identifier les entités réelles /informatiques réalisant et/ou supportant les rôles et les activités identifiées. Pour les méthodes s’intéressant à l’implémentation, la simulation n’est pas prise en compte. Les rôles sont souvent identifiés à partir de diagramme d’activités qui posent différents problèmes : quel est le problème qu’ils appréhendent ? Possèdent-ils une traduction « intéressante » dans un modèle agent ? Quel espace (ensemble d’agents) concernent-ils ? Quel est leur unité de temps (la durée) ? Pour répondre à ces questions, l’approche centrée interaction que nous proposons apparaît comme une solution.

3. Conception centrée interaction 3.1. Définition Une interaction peut se caractériser d’une part par un ensemble de scénarios, et d’autre part par un ensemble de rôles (d’agents) participant à cette interaction. Un scénario est un ensemble structuré d’événements et d’actions. L’interaction constitue une unité conceptuelle et se décrit par un ensemble de règles exprimant le contrôle des réactions des agents participants à l’interaction. Un tel ensemble de règles est appelé schéma d’interaction. La partie indépendante d’une localisation définit ce que nous appellerons une interaction type. Dans notre modélisation une localité est une unité conceptuelle et l’espace composé des trois axes (localité,

interaction, agent) constitue un espace d’interaction. Un état du système est une configuration dans cet espace. La méthode proposée se fonde sur le postulat qu’un agent donné appartient à une seule localité et participe simultanément à toutes les interactions liées à la localité. L’expression des interactions est ainsi la plus simple possible. Ceci nous permet lors de la conception, de réduire le nombre d’interaction exactement à celui souhaité, en tenant uniquement compte des localités à considérer pour l’application. Mais comment fonctionne le système qui sous-tend ce modèle ? Ce modèle définit un système d’agents dans lequel à chaque instant un agent est localisé (a est localisé en L se note L[ a[..] | …]). Une localité définit un ensemble d’interactions potentielles (L définit les interactions I1, I2, …, In se note L[I1[…] | I2[…] | … | In[…] |…]). En un lieu et pour une interaction, un agent joue un rôle. Un état du système peut donc se représenter sous forme matricielle en utilisant les notions d’interaction et de localité. Les trois dimensions de la matrice sont, les localités (elles sont trouvées par exe mple à partir du graphe de scène), les agents (a 1, a2, …, an), qui peuvent être présents ou non dans des localités et participent ou non à des interactions (I1, I2, …, Ik). L’état du système dans lequel un agent A est présent dans la sous localité L2 d’une localité L1 se notera : Systeme[ L1[L2[ I11[A[R1] | … ] | I12[A[R2]| … ] | … | I1j[ … ] | … ]] | … ]

(1)

Si les interactions I11, I12 correspondent au sous-ensemble des interactions qui concerne l’agent A, il exécute dans I11 le rôle R1 et dans I12 le rôle R2. Le fonctionnement du système s’exprime formellement par un calcul (fondé sur le calcul des Ambients). Chaque étape du calcul correspond à un changement d’état. Cette approche permet de considérer des systèmes possédant plusieurs organisations. Chacune de ces organis ations constitue un point de vue particulier pour un agent. La spécification des interactions consiste en un schéma d’interactions. L’intérêt de l’approche réside dans trois caractéristiques importantes : − L’information sur la dynamique du système n’est pas disséminée dans les agents mais exprimée de manière explicite et simple, − La modification et l’évolution d’une interaction est simple à réaliser et ne nécessite pas la modification des agents pouvant y participer, − L’information sur les actions à effectuer se trouve au plus près des données à utiliser ce qui évite leur répétition inutile sur toutes les instances. 3.2. Expression des interactions Dans notre approche, le principe retenu est de séparer l’expression de la dynamique du système en points de vue, chaque interaction type constituant un point de vue. Chaque interaction se définit par un schéma d’interaction qui précise

de manière implicite ou explicite les conditions de déclenchement des opérations des instances impliquées et les événements produits. Dans le cadre des STU, l’interaction entre un véhicule et un feu comportera une règle de la forme : « Si le feu est rouge le véhicule s’arrête ». Une telle règle présente dans un schéma d’interaction implique de manière implicite que le véhicule perçoit le feu. L’expression des schémas d’interaction peut être effectuée en utilisant un langage tel que ISL défini par l’équipe du projet Noah (Blay-Fornarino et al., 2004). Pour des raisons de conception et de vérification nous utilisons la logique linéaire (Girard, 1987). Par exemple, el schéma d’interaction de l’interaction type pieton/vehicule se définit formellement en logique linéaire par les règles suivantes : Pieton.percu(i), i.sorte(“vehicule”), pieton.onSideRoad(), pieton.goals().contains(crossRoad) =o pieton.stop(moving) Vehicule.percu(i), i.sorte(“pieton”), pieton.onZebra() =o vehicule.stop(moving)

Dans (Collé et al., 2005), nous avons montré comment analyser et évaluer des scénarios exprimés sous la forme de règles de la logique linéaire. En conception, ceci nous permet d’évaluer l’accessibilité d’une interaction. Plusieurs solutions d’implémentation existantes utilis ent un serveur d’interaction comme NOAH (Blay-Fornarino et al., 2004) ou une implémentation matricielle de l’environnement comme dans l’implémentation du modèle MIC* de F. Michel (Michel, 2004). Dans ce dernier modèle, le SMA traite le système sous forme matricielle. Ce mode induit de fait un comportement synchrone du système. Notre approche se fonde sur un autre modèle, le modèle des ambients dont le fonctionnement de base est asynchrone. Ce fonctionnement convient mieux à la modélisation d’un SMA dans lequel les agents réalisent leur comportement au rythme de leur boucle de proaction. 3.3. Modèle formel d’exécution Pour effectuer la caractérisation des comportements d’agents mobiles et plus particulièrement pour exprimer la sémantique de la communication entre agents, (Peschanski et al. 2004) ont proposés le modèle des espaces d'interaction qui permet de représenter l'état des composants du systèmes selon trois axes, les agents ou localisations, les canaux de communication et les états de ces canaux. Cette problématique se retrouve dans le concept de machine chimique proposé par (Berry et Boudol 1992). L'objectif est de traduire le fonctionnement de systèmes répartis pour lesquels les interactions ne peuvent avoir lieu que si les composants sont associés à une même localité, ici traduite par la notion de membrane. Le

fonctionnement du modèle que nous proposons est assuré par une approche formelle fondée sur le calcul des ambients. Le calcul des ambients est un modèle proposé par Cardelli et Gordon. Ils le définissent comme un moyen de spécifier la mobilité que ce soit celle d'un ordinateur portable dans un réseau ou celle d’application s'échangeant du code (Cardelli et al., 1998). Les ambients constituent ainsi un calcul avec localités (Levi et Sangiorgi, 2000). Une localité définit l’abstraction du « lieu » où s’exécutent un ou plusieurs processus concurrents. Chaque ambient possède un nom. Un ambient peut être regroupé avec d'autres ambients créant une hiérarchie. Pour modéliser la mobilité, un ambient est considéré comme pouvant être déplacé comme un tout. Un ambient s'écrit : n[P] où n est une localisation et P le processus s'exécutant à l'intérieur de cette localisation. Le processus est supposé actif et P peut être une composition parallèle de plusieurs processus. Le modèle définit ainsi des localités organisées hiérarchiquement à l'intérieur desquelles des processus peuvent s'exécuter de façon concurrente. Il se définit au moyen de primitives de base comme suit, incluant trois primitives pour la mobilité (in, out et open) : − inactivité : processus noté 0 − ambient n d'intérieur P : n[P] − composition parallèle :P|Q − composition séquentielle : M.P − entrée dans un ambient : in m.P − sortie d'un ambient : out m.P − ouverture d’un ambient : open m.P − réplication : !P − restriction : (?x).P A ces primitives s'ajoutent les deux primitives de communication suivantes : l'émission de messages < M> et la réception de messages (x).P. Le mécanisme de communication est asynchrone point à point, et ne fonctionnant que localement (l'envoi et la réception de messages sont restreints à l'intérieur d'un ambient). Le mécanisme de communication est asynchrone point à point, et ne fonctionne que localement (l'envoi et la réception de messages sont restreints à l'intérieur d'un ambient). Le calcul des ambients consiste en une suite de réductions. Ces réductions sont définies de la façon suivante : − a[in b.P | Q] | b[R] -> b[a[P | Q] | R] − b[a[out b.P | Q] | R] -> a[P | Q] | b[R] − open a.P | a[Q] -> P | Q Le calcul des ambients permet la construction d’opérateurs plus complexes permettant d’exprimer des modalités de déplacement (déplacement objectif ou non) ou la mémorisation.

4. Démarche de conception appliquée à la simulation interactive Les STU voient leur fonctionnement et leur évolution se complexifier du fait de l'augmentation constante des différents trafics (routier, marchandise...) et du cadre législatif de plus en plus contraignant. Les STU sont des systèmes complexes qui nécessitent la prise en compte de plusieurs types de contraintes : fonctionnelles, structurelles et réglementaires. La construction d'un outil d'aide au développement de structures complexes prenant en compte ces aspects nous paraît donc indispensable. La méthodologie de modélisation proposée s’intéresse à la production d’un environnement de simulation pour l’aide à la décision. Elle intègre les concepts suivants : − Modélisation orientée objets pour une première modélisation du domaine d’étude, − Spécification orientée agents pour utiliser la puissance d’expression de l’interaction, − Construction d’un système multi agents simulable dédié aux objectifs, avec prise en compte des interactions avec l’utilisateur, − Évaluation des performances par la simulation interactive. L’architecture du système informatique (voir figure 1) est réalisée selon une approche modulaire. Cette architecture sépare strictement de façon classique le noyau de simulation de la représentation graphique du système et de ses entités.

Figure 1. Architecture de l’outil d’aide à la décision L’outil possède ainsi les modules principaux suivants : − Le monde virtuel dans lequel évoluent les représentations graphiques. − Un éditeur de réseaux qui utilise la notion de graphes pour modéliser les supports des trajets aux différentes ressources. − Un éditeur de scénarios qui permet d’écrire des scénarios que l’utilisateur souhaite étudier sur son système.

− Un Système Multi Agent (SMA) qui contient toute la partie décisionnelle des agents identifiés durant l’analyse. Ce SMA est en fait décomposé en plusieurs sous-systèmes provenant de l’analyse. − Un éditeur/contrôleur servant d’interface entre le monde virtuel et le SMA. Les événements et les données transitent par ce module. L’utilisateur ne peut interagir avec l’environnement que via certains modules : le monde virtuel, l’éditeur de réseaux et l’éditeur de scénarios. Le monde virtuel est la représentation informatique du système étudié. Il est affichable indifféremment en 2D ou 3D au choix de l’utilisateur. L’éditeur de réseaux permet de construire les réseaux supportant les différents types de flux. L’intérêt des graphes est de fournir un outil mathématique permettant de vérifier certaines propriétés sur le système avant exécution, comme par exemple l’accessibilité à toutes les ressources. L’éditeur de scénarios permet à l’utilisateur d’écrire de nouveaux scénarios, et par exemple de tester des situations non prévues pour tester les capacités du système à réagir. La Conception vise entre autre à construire ce qui est noté le modèle de conception. Ce modèle possède quatre objectifs principaux : − Préciser les communications entre les classes du modèle générique de connaissance du point de vue de l’appel des méthodes, − Adapter le modèle générique de connaissance au type d'environnement à construire (simulation ou autre), et conserver l'approche orientée agents, − Valider les résultats d'analyse en éliminant les informations non pertinentes pour le logiciel et vérifier que toutes les informations nécessaires sont connues et identifiées, − Proposer un modèle de conception prenant en compte le type d’implantation prévue. Le modèle de conception que nous présentons ici (figure 2) est un modèle générique, c’est-à-dire utilisable pour tout domaine étudié. Il prend en compte le fait que nous avons identité des interactions types et des localités. Les interactions type sont localisées, i.e. sont associées à une entité précise du sous-système physique ou à une zone spatiale. Ce modèle permet d’associé un rôle à un agent lorsqu’il entre en interaction avec un autre agent, et donc de rendre contextuel le code associé au rôle. Le modèle permet de faire évoluer le système dont un état se présente sous forme naturelle comme nous l’avons indiqué en (§3.1 (1)). En pratique, l’évolution du système est représentée par un calcul, un état étant représenté par un Ambient (Cardelli et al., 1998). L’expression sous forme d’ambients du système permet de valider formellement le modèle sous forme d’agent interagissant. Ainsi l’expression sous forme d’Ambient de l’état d’une voie de circulation vIN sur laquelle deux interactions interactionFV et interactionVV sont possibles. Le modèle exprime qu’un véhicule entrant sur la voie déclenche la création des deux interactions. vIN[ interactionFV[ !open enveloppe.0 | 0]

| interactionVV[ !open enveloppe.0 | feuNE[perception[0] | action[0] | interne[0]] ] | "move in interactionFV entrant".nu w.w[in interactionFV. enveloppe[out w. open w.entrant[0]]] | "move in interactionVV entrant".nu x.x[in interactionVV. enveloppe[out x. open x.entrant[0]]] ]

Le modèle intègre les fonctions suivantes : addAgent, makeActiveAgent, percevoir, changeRole et getInteraction. L’instanciation du modèle conduit à créer des espaces d’interaction vides (interactions type localisées) et à ajouter (addAgent)

Figure 2. Modèle de conception pour l’interaction l’ensemble des agents participants potentiellement à cette interaction. Dans le calcul des Ambients, cela revient à indiquer à un gestionnaire les demandes d’entrées dans l’espace d’interaction auquel il aura à répondre. L’entrée dans l’espace d’interaction (makeActiveAgent) se traduit par la création pour chaque interaction d’un Ambient représentant l’agent et exécutant le processus correspondant à son rôle. 4.1. Modèle d’un agent Un agent exécute une boucle de proaction perception, décision, action. La structure générale de l’agent est définie de la façon suivante : // Perception _liste_percu = percevoir();

pour tout agt in _liste_percu = activerInteraction(agt); pour toute I in L.Interaction() do I.getInfluence(); // Décision _Actions = decider(); // Action pour toute a in _Actions faire a.performAction();

La perception consiste d’une part à demander au monde virtuel de fournir la liste des entités perçues (viewFirst(angle, dist, "nom entité", _pi_/2, 5, 0);) d’autre part à solliciter pour chaque entité la création d’une interaction. L’expression en langage oRis (Harrouet 2000) de la perception est la suivante : void Vehicule::perception(){ float angle; float dist; _LaVoie = (Voie) viewFirst(angle, dist,"Voie",_pi_/2,5,0); if ((_LaVoie != NONE) && (_LaVoie != _LaVoiePrecedente)){ _LaVoiePrecedente = _LaVoie; println(this," est sur la voie ",_LaVoie); } if (_LaVoie != NONE){ _LaVoie->interact(this);} }

La décision est un mécanisme qui se déroule en deux temps. Dans un premier temp s, l’entité « récupère » le résultat des interactions actives appelée « influence » selon le principe développé par Ferber. Dans un deuxième temps, un programme de décision synthétise ces influences pour produire la mise à jour des paramètres d’exécution. Dans l’exemple suivant la technique de décision est simplifiée. Une décision apparaît comme une fonction qui à un ensemble _listeInfluences associe un ensemble d’action à effectuer. La forme de cette fonction et sa conception ne font pas l’objet de ce papier. void Vehicule::decision(){ if (_listeInfluences.length()>0){ Influence uneInfluence = _listeInfluences.popBack(); if ((uneInfluence->_LeContenu == "stop")&&(_Etat==0)){ // véhicule arrété au feu _Vitesse = 0; _Etat = 1; } if ((uneInfluence->_LeContenu == "freine")&&(_Etat==0)){ // véhicule freine aux abords du feu _Acceleration = -0.01; } … if ((uneInfluence->_LeContenu == "go2")&&(_Etat==1)){ // la voiture est assez loin, le véhicule avance _Acceleration = 0.0005; _Etat = 0; } }

}

L’action consiste ainsi à activer toutes les actions définies lors de la décision. 5. Application : Cas des systèmes de trafic urbains Nous nous intéressons ici essentiellement à l’impact du comportement des usagers sur le fonctionnement des Systèmes de Trafic Urbain (STU). Dans le cadre du projet OSPDU (Organisation du Stationnement dans le Plan de Déplacement Urbain), nous souhaitons formaliser la mise en œuvre d’un PDU (Plan de Déplacement Urbain) dans les STU par la caractérisation des comportements des usagers. Le but final est la définition d’un outil d’aide à la décision permettant entre autre l’optimisation des parkings en étudiant différentes heuristiques de gestion et de simuler le comportement complexe des usagers. Cette approche est liée à l’observation que, dans un STU comme dans de nombreux systèmes complexes, l’évolution globale du système émerge de l’interaction entre toutes les entités du système, chacune ayant son propre comportement. Nous décrirons dans cet section uniquement une partie du travail afférant au Sous-Système Logique (SSL) et nous préciserons ensuite quelques aspects de l’implémentation. Le SSL (voir extrait figure 4) identifie quatre types flux : décision, information, véhicule et piéton. Ce modèle nous permet de distinguer des flux de véhicules/piétons différents suivant leur type. Ce type peut être associé à des propriétés physiques, à des motifs de trajet,… Le modèle de communication permet par exemple d’identifier des interactions possibles entre les véhicules (car ils utilisent le même réseau routier), entre les piétons, et entre les véhicules et les piétons (voir figure 3), et entre les véhicules (ou piétons) et la signalisation. Les associations de ce diagramme peuvent être colorées pour séparer différents cas : l’utilisation d’une ressource, la consultation d’un état, l’envoi d’information… Ceci permet de déterminer plus facilement les activités associées. La figure 4 représente un extrait du diagramme de communication centré sur les véhicules et les piétons. Ce modèle nous permet d’identifier entre autre les interactions types suivantes : véhicule/véhicule, véhicule/piéton, véhicule/signalisation, piéton/signalisation. La modélisation précédente est « statique » et ne permet pas de distinguer les entités des rôles qu’elles réalisent, et donc de spécifier les interactions entre les différentes entités.

Figure 3. Extrait du SSL

Figure 4. Extrait du modèle de communication L’utilisation du modèle de communication a permis d’identifier des interactions type entre agents telles que : − Un véhicule et un autre véhicule, − Un véhicule et un piéton, − Un véhicule et une signalisation. Pour les interactions types identifiées, il est nécessaire de préciser le rôle de chacun des intervenants pour chacune de ces interactions. Par exemple, dans le cas de l’interaction véhicule/véhicule, plusieurs cas sont possibles : − Un véhicule peut être le véhicule suiveur d’un autre,

− Un véhicule peut être le véhicule de tête, − Un véhicule peut en doubler un autre. Ces rôles sont obtenus en réalisant des diagrammes d’activité avec ligne de nage où chaque ligne de nage correspond à un des agents et en explicitant les scénarios associés à chacun des espaces d’interactions. Cette explication peut être réalisée sous forme textuelle ou sous forme de dessins relatifs au domaine. Dans le cadre des STU, ceci correspond à la mise en situation de deux véhicules dans des infrastructures types, et de préciser le(s) comportement(s) qui doivent être observés. Par exemple, lorsqu’un véhicule en suit un autre, il est communément admis qu’il observe prioritairement le véhicule qui le précède. A la suite de ce diagramme, les agents intervenants dans l’interaction peuvent être «remplacés » par les rôles correspondant (par exemple ici suiveur et prédécesseur). Les agents sont identifiés comme les entités actives capables entre autre d’endosser différents rôles. Dans ce cadre, nous avons identifiés les piétons, les véhicules et les contrôleurs comme des agents (ceci relativement aux différents extraits de diagrammes présentés). Pour une interaction type identifiée précédemment, nous décrivons ici de une à plusieurs interactions. La localisé les interactions types est effectuée selon les éléments du sous-système physique qui ont été retenus pour la conception. Nous obtenons dans le diagramme de classes de conception présenté dans la figure 5. Espace_Interaction Rôle

…

getRole() executeRole() +changeRole()

Interaction_Type Entree-Carrefour

Agent

activeRole() *

*

Véhicule-piéton

Véhicule-signalisation

Voie …

Véhicule-véhicule

preceive() changeRole() getInteraction()

Véhicule-route VVsuiveur-prédecesseur

VVdépasser

VVcroiser

Figure 5. Modèle de conception pour l’interaction pour les STU (extrait)

6. Conclusion Dans ce papier, nous proposons une méthodologie, de conception d’environnement logiciel multi-agents, centrée sur l’interaction. Elle permet de répondre plus facilement à la formalisation de la connaissance en s’appuyant sur une plus grande facilité à l’extraire localement. Dans cette approche les interactions constituent des points de vue permettant d’appréhender la complexité en particulier en utilisant différents niveaux spatiaux, et temporels. Le modèle proposé est fondé sur un modèle formel dans lequel les changements d’états sont le résultat de transformations, « déplacements », d’envois de messages, définies dans le calcul des ambients. La méthodologie de conception proposée s’appuie sur d’une part la formalisation des scénarios (définis dans une modélisation UML) par des règles exprimant les interactions en logique linéaire et d’autre part sur une architecture capable de représenter et faire fonctionner des entités respectant ces contraintes. Cette architecture est mise en œuvre sous forme de SMA. L’introduction de la logique linéaire et des ambients permet la vérification formelle de certaines propriétés comme l’accessibilité de ressources. Une architecture de l’environnement logiciel à produire est proposée et s’articule autour de la proposition faite de pouvoir immerger l’utilisateur dans un monde graphique virtuel en 3D. Une application partielle de la méthodologie aux Systèmes de Trafic Urbain (STU) est présentée. Les travaux se poursuivent pour développer une application spécifique aux STU. L’implantation du modèle de conception pour l’interaction est en cours de réalisation.

7. Bibliographie Augeraud, M., Boussier, J.M., Collé, F., Estraillier, P. and Sarramia, D. 2005. Simulation Approach for Urban Traffic System: a multi-agent approach. International Conference on Industrial Engineering and Systems Management IESM’2005, Marrakech (Maroc). Berry, G., Boudol, G. The Chemical Abstract Machine. Theorical Computer Science, 1992, 96, 217-248 Blay-Fornarino, M., Emsellem, D., Pinna-Dery A-M. and Riveill, M. 2004. Un service d’interactions : principes et implémentation. RSTI – série TSI, ISBN 2-74162-0913-6, 23(2), pp 175-204 Cardelli, L. and Gordon, A., D. 1998. Mobile Ambients. In Foundations of Software Science and Computation Structures: First International Conference, FOSSACS '98, SpringerVerlag, Berlin Germany, citeseer.ist.psu.edu/cardelli98mobile.html. Collé, F., Champagnat, R., and Prigent, A. 2005. Scenario Analysis based on Linear Logic. Proceedings of International Conference on Advances in Computer Entertainment Technology ACE 2005, Spain. DeLoach, S.A., 1999. A Methodology and Language for Designing Agent Systems. Proceedings of Agent Oriented Information Systems, p. 45-57.

Ferber, J. et Gutknecht, O., 1998. Aalaadin: a meta-model for the analysis and design of organizations in multi-agent systems. Proceedings of the Third International Conference on Multi-Agent Systems, p.128-135. Girard, J.-Y., 1987. Linear Logic, Theoretical Computer Science, London Mathematical 50:1, pp. 1-102. Gourgand, M. and Kellert, P., 1992. An Object-Oriented Methodology for Manufacturing System Modelling. Proceedings of the 1992 Summer Computer Simulation Conference., pp 1123-1128. Reno, Nevada. Gutknecht, O., Ferber J., 1999. Vers une méthodologie organisationnelle de conception de systèmes multi-agents. Actes des 7èmes Journées Francophones d'Intelligence Artificielle et Systèmes Multi-Agents (JFIADSMA'99), p. 93-104. Harrouet, F. oRis : s'immerger par le langage pour le prototypage d'univers virtuels à base d'entités autonomes Thèse de l’Université de Bretagne Occidentale, 2000 Iglesias, C., Garrijo, M. and Gonzale, J., 1999. A Survey of Agent-Oriented Methodologies, Proceedings of the 5th International Workshop on Intelligent Agents V (ATAL-98) .Vol. 1555, Springer-Verlag p. 317-330. Levi F., Sangiorgi D., 2000. Controlling Interference in Ambients , Symposium on.Principles of Programming Languages, , p. 352-364. Michel, F. 2004. Formalisme, outils et éléments méthodologiques pour la modélisation et la simulation multi-agents. Thèse de doctorat, Univ. des Sciences et Techniques du Languedoc. Odell, J., Parunak, H.V. et Bauer, B., 2000. Extending UML for Agents. Proceedings of Agent Oriented Information Systems Workshop at the 17th National conference on Artificial Intelligence (AAAI). Padgham, L. and Winikoff, M., 2002. Prometheus: A Methodology for Developing Intelligent Agents. Proceedings of the Third International Workshop on AgentOriented Software Engineering, at AAMAS, Bologna, Italy. Peschanski F., Affeldt R., and Briot J-P, 2004 Les espaces d’interaction : vers une géométrie des systèmes d’agents mobiles. In RSI-L’objet LMO’04, pages 31–45, Paris, France. Shehory, O. and Sturm, A. 2001. Evaluation of modeling techniques for agent-based systems. In Proceedings of the 5th International Conference on Autonomous Agents (Montreal, Ont., Canada, June). ACM, New York, pp. 624–631. Tveit, A., 2000. A survey of Agent-Oriented Software Engineering. Report, Norwegian University of Science and Technology. Wooldridge, M., Jennings, N. and Kinny, D., 2000. The Gaia Methodology for AgentOriented Analysis and Design. Autonomous Agents and Multi-Agent Systems, 3(3), p. 285312, Kluwer Academic publishers Yan, Q., Shan, L-J, Mao, X-J, AND Qi, Z-C. 2002. ROMAS: A role-based modeling method for multi-agent system. http://www.auml.org/auml/supplements/RoMAS.pdf. Accédé le 08 May 2006